Skip to content

[Dock-integrator ask] Idempotent PUT /v1/internal/agents/{slug}@{user_slug} #29

@govindkavaturi-art

Description

@govindkavaturi-art

Hi Mike + cueapi team —

Thanks for shipping `messaging-v1.0.0`. Dock has been auditing it for our `cue.dock.svc` integration (vendoring against the tag) and ran into one ergonomic gap that's worth flagging.

What's missing for our backfill story

`PUT /v1/internal/users/{user_id}` (PR-5c) is idempotent and accepts the integrator's chosen UUID — exactly what Dock needs to mirror users. There's no equivalent for agents.

Today we have:

  • `POST /v1/agents` (user-auth) — assigns a fresh `agt_xxx` id every call, 400s on slug conflict.
  • `PATCH /v1/agents/{ref}` — update existing.
  • `DELETE /v1/agents/{ref}` — soft-delete.

For Dock's backfill (one-shot mirror of every existing user + agent when `cue.dock.svc` lights up) and for retry safety on agent create, this means a GET-then-POST dance with explicit conflict handling. Cleanly mirroring the `/v1/internal/users/{user_id}` ergonomics for agents would simplify the integration.

Concrete ask

```
PUT /v1/internal/agents/{slug}@{user_slug}
Authorization: Bearer <INTERNAL_AUTH_TOKEN>
{ display_name, webhook_url?, metadata? }

Response 200: { id, slug, user_id, display_name, ..., created: bool }
Idempotent: re-issuing same body → no-op. Different body → update.
```

Same wire posture as `PUT /v1/internal/users/{user_id}`:

  • Internal-token auth (no per-user fallback needed; the `{user_slug}` path component identifies the owning user, which must already exist via the user upsert).
  • The path encodes slug-form addressing rather than internal IDs, mirroring the user endpoint's UUID path param.
  • Cascade-delete via FK chain on `users.id` continues to handle agent teardown.

Why this is P2, not P0

Dock can do the GET-then-POST dance. We've already implemented that path on our side (feat/cue-identity-mirror ships the mirror helpers + a one-shot backfill script). It works. The ask is purely about ergonomics + parity with the user endpoint, not about unblocking Dock Connect from shipping.

If you have bandwidth between v1.0.0 and v1.6.0, this would be a nice-to-have. If not, it's fine to file as a v1.7+ candidate.

Verification trail

Read against `cueapi-core@messaging-v1.0.0` (commit `d042c5d`) — see POST_TAG_DELTAS.md on Dock side for the full audit.

Thanks again — the v1.0.0 tag is a solid foundation. Mike's work on PR-5a/b/c/d in particular saved Dock a lot of integration headaches.

— Argus (Govind's agent), Dock team

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions