Report install/deploy result for a release
const url = 'https://api.aetherpush.com/v0.1/public/codepush/report_status/deploy';const options = { method: 'POST', headers: {'Content-Type': 'application/json'}, body: '{"deployment_key":"AbCdEf1234567890","app_version":"1.0.0","client_unique_id":"8f4e2c1a-9b3d-4f5e-a6c7-d8e9f0a1b2c3","label":"v3","status":"DeploymentSucceeded"}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://api.aetherpush.com/v0.1/public/codepush/report_status/deploy \ --header 'Content-Type: application/json' \ --data '{ "deployment_key": "AbCdEf1234567890", "app_version": "1.0.0", "client_unique_id": "8f4e2c1a-9b3d-4f5e-a6c7-d8e9f0a1b2c3", "label": "v3", "status": "DeploymentSucceeded" }'Called by the React Native SDK after attempting to install a JS bundle update. Used to compute install success/failure metrics and active-app counts per release.
The server is permissive about field shape — both snake_case and camelCase keys are accepted. Modern SDKs (>= 1.5.2-beta) include idempotency-aware logic that suppresses duplicate success reports.
Request Bodyrequired
Section titled “Request Bodyrequired”Body shape for report_status/deploy. Reports the result of a
client attempting to install a package. Most fields are optional;
the SDK populates them based on what it knows. The server accepts
both camelCase (deploymentKey) and snake_case (deployment_key)
field names; snake_case is the canonical form.
object
Package label as minted by the server, e.g. v3. When the field
is present and non-empty it must match this pattern, and a
request for a recognised deployment_key that carries any other
value is rejected with a 400. Omit the field, or send an empty
string, for a binary-version success report; the server then
counts the report under app_version instead. A
DeploymentFailed status always requires a valid non-empty
label and is rejected with 400 without one.
Outcome of the install attempt. DeploymentFailed requires a
valid package label. Failure counts are per distinct device:
when a client_unique_id is present the server counts a device
at most once for that release, and a report that omits the
device id is accepted without moving the failure counter.
Success counts still follow the active-label idempotency rule
and can move without a device id.
Optional coarse client platform. Invalid values are dropped and never stored. Not used for update selection.
Optional OS major version only (digits). Full version strings are truncated to the leading major when valid; otherwise dropped.
Optional React Native version as major.minor. Other shapes are
dropped.
Optional Aether/CodePush SDK version string. Distinct from the
X-CodePush-SDK-Version header used for metrics branching.
Example
{ "deployment_key": "AbCdEf1234567890", "app_version": "1.0.0", "client_unique_id": "8f4e2c1a-9b3d-4f5e-a6c7-d8e9f0a1b2c3", "label": "v3", "status": "DeploymentSucceeded"}Responses
Section titled “Responses”Status accepted.
Lightweight acknowledgment for status reports. Sent in some legacy code paths.
object
Example generated
{ "status": "example", "message": "example"}Headers
Section titled “Headers”Present on legacy acquisition endpoints. Signals the endpoint is
deprecated in favor of its canonical /v1/public/aether/* successor.
The value is the string true.
Example
trueRFC 8288 link header with two link values: the canonical successor endpoint via rel=“successor-version”, and the CodePush migration guide via rel=“deprecation”.
Example
</v1/public/aether/update_check>; rel="successor-version", <https://docs.aetherpush.com/migration/codepush/>; rel="deprecation"Missing required fields, an invalid status value, a
DeploymentFailed report without a valid package label of the
form v1, or any other non-empty label that is not of that
form. Once the required fields and app_version are
well-formed, an unrecognised deployment_key answers 200
rather than 400.
Standard error envelope. code is the stable machine identifier for
client branching and i18n. The wording of error is a human-readable
fallback and is not part of the contract. Specialized responses keep
narrower code enums where clients already branch on them.
object
Human-readable error message.
Stable machine code. Prefer this over matching on error. The
values this API can answer with are listed in the ApiErrorCode
schema of the raw document at
https://api.aetherpush.com/openapi.yaml. The field stays an
open string here so that a release adding a value does not
invalidate this response.
Unique identifier for the request, also exposed as the X-Request-Id response header.
Example
{ "error": "The requested resource was not found.", "code": "not_found", "requestId": "req_abc123"}The request did not arrive through the trusted edge. This endpoint is unauthenticated; 403 is that refusal, not a missing bearer token.
Standard error envelope. code is the stable machine identifier for
client branching and i18n. The wording of error is a human-readable
fallback and is not part of the contract. Specialized responses keep
narrower code enums where clients already branch on them.
object
Human-readable error message.
Stable machine code. Prefer this over matching on error. The
values this API can answer with are listed in the ApiErrorCode
schema of the raw document at
https://api.aetherpush.com/openapi.yaml. The field stays an
open string here so that a release adding a value does not
invalidate this response.
Unique identifier for the request, also exposed as the X-Request-Id response header.
Example
{ "error": "Forbidden", "code": "forbidden", "requestId": "req_abc123"}The request failed for a reason the server does not classify
as retryable, so it carries no Retry-After. A database
failure the server recognises answers 503 above instead.
Everything else answers here, a Redis failure and a defect
alike, so this status is not by itself evidence of either.
Standard error envelope. code is the stable machine identifier for
client branching and i18n. The wording of error is a human-readable
fallback and is not part of the contract. Specialized responses keep
narrower code enums where clients already branch on them.
object
Human-readable error message.
Stable machine code. Prefer this over matching on error. The
values this API can answer with are listed in the ApiErrorCode
schema of the raw document at
https://api.aetherpush.com/openapi.yaml. The field stays an
open string here so that a release adding a value does not
invalidate this response.
Unique identifier for the request, also exposed as the X-Request-Id response header.
Example
{ "error": "The requested resource was not found.", "code": "not_found", "requestId": "req_abc123"}The deployment key could not be resolved because the server
could not reach its database, and nothing was cached for that
key. Retryable: Retry-After carries the seconds to wait.
This is the cold-key case, not a whole-server refusal: a key
the server still holds in its deployment cache resolves
normally during the same outage, and the rest of this
request reads Redis rather than the database.
Returned with HTTP 503 when the server could not complete an
operation for a reason it expects to pass, and says so rather than
answering as though it had. On the management API, a release or
deployment write could not finish because of database contention
(lock wait expired, deadlock, or a serialization failure) and
nothing was written, or a release
upload could not read back the package it had just stored in order
to sign its URL. On the
acquisition endpoints, a database read the request depends on
could not be completed: resolving a deployment key with nothing
cached for it, reading that deployment’s releases, or refreshing
the download URL of the release it would serve. The release and
download-URL reads answer this way for the failures the server
recognises as transient, and the deployment lookup answers this
way for any failure it cannot serve from a cached entry, so an
outage no longer produces a different status depending on which
of them it reached.
retryAfterSeconds is the minimum interval before a
retry is useful for the path that failed, and is also sent as the
Retry-After response header. Management lock-contention 503s use
the commit lock wait; acquisition and other transient-read 503s use
the deployment-cache failure grace. Those intervals are independent
and can differ. code is connection_failed on every response this
schema describes, management lock contention included. The operation
and the message are what distinguish the paths.
object
Example
{ "error": "This release could not finish because another release was committing to the same deployment. No release was created. Please try again.", "code": "connection_failed", "retryAfterSeconds": 5, "requestId": "req_abc123"}Headers
Section titled “Headers”Seconds to wait before retrying.