RCS Verification Corrections and Screenshot Retention
Carriers expect conversation screenshots with every RCS verification submission, including a correction of one they already hold. Since 2026-10-15, Orbit keeps the screenshots from your last accepted submission and attaches them for you when a correction carries no new ones. This page describes what is kept, where it lives, when it is deleted, and what is never kept. For the initial submission contract (fields, document roles, country rules) read the RCS brand verification KYC walkthrough; for the console flow, the RCS brands console guide.1. What changed on 2026-10-15
Before this change, Orbit streamed your uploads straight to the carrier and kept only counts. A correction therefore had to carry its own screenshots, and the carrier refused a correction sent without them (screenshotUris cannot be empty). If you no longer had the originals, you could not correct the agent at all.
Now:
- Orbit stores the conversation screenshots of every accepted verification submission, per agent.
- A correction sent without new screenshots goes out carrying the stored set.
- KYC documents are still not stored. Carriers accept corrections carrying no identity paperwork, and Orbit does not retain business registrations or director IDs against a requirement it has never been shown.
2. What is retained and where
The stored set lives on the agent’s row under theverification_screen_images config key:
- A durable object key, never the signed URL. An upload returns a signed URL that expires within an hour; storing it would pin a handle that dies in the row. The descriptor stores the object key, which stays valid, plus the file id used to delete the object.
- Your own media prefix. Objects sit in the platform media bucket under your tenant’s prefix, the same place your other uploaded media lives.
- Replaced by the newest submission. A submission that carries new screenshots replaces the stored set, but only after the carrier has accepted it and the new set is committed to the row. The superseded objects are deleted after the replacement commits; if the replacement is interrupted, the previous set stays readable.
3. The correction flow
When aPOST /api/v1/rcs/bots/:id/verify call is a correction (a submission already exists for the agent) and carries no screenImages[], Orbit loads the stored set, re-attaches it, and re-stamps the conversation-screenshot bindings so they name the files actually attached. You change the field you came to change; the screenshots travel with you.
A correction that attaches its own screenImages[] always uses yours. The stored set is not consulted, and it is replaced by your new set once the submission is accepted.
The re-send is fail-soft. If the stored set is absent, drifted, or unreadable, Orbit sends the correction exactly as you submitted it rather than blocking it. The carrier then answers with its missing-screenshots refusal, and Orbit translates that refusal into actionable advice on what to attach. The KYC walkthrough covers answering a refusal.
4. The retention boundary
- Committed-mode cleanup. Storing runs only after the carrier accepts the submission, and it can never fail the submission. If objects were uploaded but nothing could be recorded on the row, exactly those uploads are deleted; once the row write commits, cleanup never deletes objects the row now names.
- Tenant-owned keys only. A stored descriptor is row data, and row data cannot address objects outside your tenant’s prefix: an object key is only ever read or deleted when it starts with your
<schema>/prefix. The check applies at read and again at delete. - Nothing unresolvable is kept. An upload whose object does not resolve to a tenant-owned key is deleted on the way in instead of being recorded.
5. Purge on agent deletion
Deleting an agent deletes its stored screenshots with it. Orbit reads the stored descriptors before the row is removed and deletes the objects after the deletion is confirmed, so a delete that matches nothing never touches another agent’s screenshots. Removing the row does not by itself reach the objects in storage, which is exactly why the purge reads first and deletes second: without it, the screenshots would outlive the agent.6. What is not retained
kycdocs[] streams straight through to the carrier and never reaches storage. Identity paperwork stays yours: you upload it, the carrier reviews it, Orbit never holds a copy. The demo video is referenced by video_url; Orbit stores the link you send, not the video.
7. Known limitation
Two concurrent corrections on one agent that both carry new screenshots can strand the loser’s uploads: both write the stored-set key, the later write wins, and the loser’s objects are left unnamed under your media prefix. Serializing the two would hold a row lock across storage round-trips on a path the carrier has already accepted, so the race is left open by design. The stored set itself stays consistent (one winning set), and the exposure is bounded by the 10-file ceiling per submission. Send corrections for one agent in sequence if you want to avoid it entirely.8. Operator checklist
- A correction failed with a missing-screenshots refusal. The stored set was absent or unreadable for this agent. Re-send the correction with fresh
screenImages[](up to 10, 5 MB each); once accepted, that set becomes the stored set for the next correction. - Force fresh screenshots. Attach new
screenImages[]to the next accepted submission. The stored set is always the set the carrier last received; there is no separate rotate call. - Drive a removal. Delete the agent and the purge in section 5 removes the stored objects. There is no per-object delete for verification screenshots.
- Erasure and DSR posture. Stored screenshots are your media under your tenant prefix and are removed with the agent; Orbit does not promise platform-mandated retention periods. This page tells you what is kept and how to drive a removal. For the identity paperwork you upload yourself, see KYC documents.