Register a destination for results

Before you start

You need an administration credential, a stored write credential, and one workflow whose output you want delivered. A work key cannot register a destination.

Decide who owns the destination before you register it. Somebody has to renew its authority and answer for what lands there.

Choose a destination your account allows

Describe the destination family first, then list what is already registered. Do not assume a target is permitted because you can reach it yourself.

The destination must satisfy two things at once. Your account policy has to allow it, and the workflow's output declaration has to support it. A destination that passes only one of those refuses at admission, not at delivery.

Register the smallest scope that works. A prefix or a dataset is a better grant than a whole account.

Choose an immutable write mode

Results are written once, to a new location, and never over an existing one. Choose the write mode that reflects that.

Your request's output object declares the format, the destination and the result partition. A repeated delivery writes a new partition rather than replacing the previous one, so an earlier result stays readable and explainable.

This is why a re-delivery never needs a re-run. The bundle already exists; only the write is repeated.

Test commit permission before you depend on it

A destination write finishes in two stages. Bytes are written, then the write is committed and verified.

Many credentials can create an object but cannot commit or finalize one. That gap does not appear until real work is delivered, which is the worst moment to find it.

Use the destination family's test operation and confirm it reaches a committed state. If it stops short, fix the grant now.

Record the scope, expiry and recovery

Write three things down where your team can find them, next to the destination's own record.

• The exact scope you granted, and the credential reference it uses.
• The expiry of the delivery authority, and who renews it.
• What to do when a delivery fails, including who holds the destination.

Delivery authority is deliberately time-bounded. AUTHORITY_EXPIRED means the permission lapsed, not that your result is lost.

Confirm success

The destination reads back as VERIFIED, its test reaches a committed write, and a job's delivery progresses to COMMITTED and then to CUSTOMER_ACKNOWLEDGED.

Do not treat WRITTEN_UNVERIFIED as done. The bytes exist, and nothing has confirmed them yet.

When a delivery fails

Each failure names its own reason and its own next action. Read them together.

• AUTHORITY_EXPIRED — renew the authority, then retry the delivery.
• WRITE_FAILED — check the destination is reachable and the grant is intact, then retry.
• VERIFY_FAILED — the write could not be confirmed, so re-verify before treating it as delivered.
• COMMIT_CONFLICT — something else holds the target partition, so resolve it and deliver to a new one.
• QUARANTINED — the delivery is held pending review; follow the stated next action.

None of these requires re-running the work. See what each delivery state means before you retry anything.

Set spend ceilings and approvals