You keep your provider, your key and your billing. R-Sym sits in front of the call and hands you back something smaller to send.
You will receive a key beginning rsk_live_. It is shown once and stored hashed, so keep it somewhere you control.
Your key goes in the Authorization header. Your provider key does not go anywhere — it stays with you.
curl https://api.r-sym.com/v1/submit \ -H "Authorization: Bearer $RSYM_KEY" \ -H "Content-Type: application/json" \ -d '{ "tool": "optimize_payload", "payload": "...your context..." }'
Every response has the same shape. deliverable is what you send on to your provider, where you were going to send your original context: same endpoint, same model, same account, same key. dollarsSaved is what it saved you, settled against their invoice rather than our estimate.
{
"status": "ok",
"requestId": "2325138bcba040e1af6e8441e4dad1c6",
"outcome": 0,
"deliverable": "...send this instead...",
"dollarsSaved": 0.0000,
"latencyMs": 0
}
Errors carry a code and the matching HTTP status. A caller reading only the status line and one reading only the body reach the same conclusion.
| Code | HTTP | Meaning | What to do |
|---|---|---|---|
| — | 200 | Accepted and processed. | Use the deliverable. |
| RS-401 | 401 | Missing, unknown or revoked key. | Check the header, then the key. |
| RS-402 | 402 | Account on hold. | Settle the balance. |
| RS-403 | 403 | Usage cap reached, or payload too large. | Split the payload or raise the cap. |
| RS-429 | 429 | Rate limited. | Back off and retry. |
| RS-500 | 500 | Fault on our side. | Retry. Quote the requestId if it persists. |
Access is granted by request while the platform is in preview.