elastly package is the supported way to call Elastly from Python. The request and response types
are generated from the same OpenAPI contract our servers validate against, so they
cannot drift from the API. On top of that it adds what every integration needs: a price call that never
breaks your quote screen, typed errors, webhook verification, and a connector that pages, checkpoints,
retries, and reports for you.
Keys and scopes
Create API keys under Settings → API keys. Scopes are separate on purpose: a serving key can never write your catalog, and a connector key can never read prices.The one thing to get right: the decision id
Every priced line comes back with apricing_decision_id. Store it in your own system, on the quote
line it priced. When that quote later closes and you send it back to Elastly, the id ties what Elastly
recommended to what your rep actually charged. That difference is what the model learns from.
Skip it and everything still looks like it works: prices serve, quotes ingest, dashboards fill. But the
model learns nothing from your quotes, and nothing tells you. So wire it first:
Price a line, with a fallback
A price call usually runs inside a rep’s quote screen or a checkout render. If Elastly is slow or down, your system must keep working. The SDK makes that a policy you declare, not code you write:source == "fallback"
and the cause attached. If your fallback returns None, you get source == "unavailable", an explicit
typed no-answer.
Requests that mean your call is wrong (invalid_request, feature_not_enabled) always raise a typed
error, because a bug in your integration is not an outage to paper over. For batch jobs where a wrong
price is worse than no price, use throw_on_failure, which raises on everything:
get_many prices up to 100 lines in one HTTP call. One unknown SKU fails that line alone, never the
whole batch.
Typed errors
Every error is a typed exception carrying the stable error code and the request id, so support can find the exact call. Catch the specific class or the base:UnknownProductError, NoCostBasisError,
MonthlyVolumeExceededError, and the rest), all subclassing ApiError, which subclasses
ElastlyError. Catch ElastlyError to handle anything, including network and timeout faults.
Verify a webhook
verify checks the signature in constant time, rejects anything older than five minutes, and returns a
typed event. It raises SignatureVerificationError on a bad signature, a replay, or a malformed body.
The four event types are sync.completed, recommendation.created, price.written_back, and
test.ping.
What the SDK handles for you
- Idempotency. Every mutating call carries a key that stays stable across retries, so a retried price call can never double-count against your plan.
- Retries. Failed calls back off with full jitter and honor
Retry-AfterandRateLimit-Reset. - A circuit breaker. After repeated failures it stops hammering Elastly and goes straight to your fallback, then probes once to recover.
- Fail-open telemetry. Every call that falls open reports itself to Elastly (fire and forget, never on your latency path), so an outage that hit your quote screen shows up in your dashboard.
Build a connector
To push your own ERP or storefront into Elastly, the SDK ships a connector runtime: implement a few functions that read your data, anddefine_connector runs the whole sync, with paging, checkpoints,
retries, and write-back leases handled for you.
Build a connector
Feed your data in, apply approved prices back, in Python or any other language.
Versioning
The SDK’s major version is bound to the API version in the URL. Every0.x and 1.x release talks to
/api/v1, so an upgrade within a major is always safe.
The source is on GitHub. It is generated, so file an issue
rather than a pull request against generated code.