catalog.updated webhook. Once a day, when anything in your catalogue changed, you get the price changes, new packages and withdrawn packages at your own prices. Each list holds at most 100 entries, largest price moves first; the counts are always complete, and truncated is true when a list was cut short.

What to do: Optional. Tick it on the Developers page - it is not part of "all events". When truncated is true, read GetPackages?all=true for the rest.

Webhooks →

catalog.price_scheduled webhook. Announces price increases before they reach you, with oldPrice, newPrice and the effectiveAt date for each package. Until that date you keep paying the old price.

What to do: Optional, and only sent while advance notice of increases is in force for your account. Tick it on the Developers page to receive it.

Webhooks →

The daily catalogue report no longer loses a day's changes when its email fails to send. They are now reported on the next run instead of being dropped.

What to do: Nothing.

GetPackages accepts includeDetails=true, which adds packageData.networks to every row - the same carriers and 5G flags GetPackageDetails returns - so a separate details call per package is no longer needed.

What to do: If you call GetPackageDetails for every package, drop that loop. Without the flag, networks is null, which means "not asked for"; an empty list means "no networks".

Packages →

GetPackages accepts all=true, which ignores page and pageSize and returns up to 10,000 rows in one response. Combine it with includeDetails=true to read the full catalogue with its networks in a single request.

What to do: Send Accept-Encoding: gzip and cache the result - it is a large response that changes far less often than you would read it.

Packages →

API responses are compressed (gzip or brotli) when your client asks for it.

What to do: Nothing. Most HTTP libraries already send the header and decompress for you.

lifecycle on GetOrderDetails: whether the customer has downloaded and installed the eSIM, and on which phone. It carries state (NotDownloaded, Downloaded, Installed, Enabled, Disabled, Deleted or Blocked), device, eid and a dated events list, newest first.

What to do: Read lifecycle: null as "unknown", not "not installed" - it is null on plans whose network does not report installs, and on test orders.

Orders →

esim.installed and esim.activated webhooks. esim.installed fires when the customer installs the eSIM; esim.activated when the plan starts counting, with activatedAt and, once known, expiresAt. Each fires once per eSIM.

What to do: Optional, and instead of polling GetOrderDetails for the install. Tick them on the Developers page - they are not part of "all events".

Webhooks →

Live usage and install status are now reported for more plans, and the direct install links (iosInstallLink, androidInstallLink) are returned for more plans too.

What to do: Nothing. Fields that were null because a plan did not report them may now be filled in, so don't treat null as permanent.

GetOrderDetails reads from the network, which only updates usage every few hours - on some carriers once a day. Reads are now held briefly (usage for up to ten minutes, install status for two), so polling faster than that returns the same answer.

What to do: Poll no more often than every few minutes, or use the webhooks above and don't poll at all.

Fulfilment →

On some plans the activation and expiry times (usage.startDate, usage.endDate) and install event dates were read as UTC when the network reports them eight hours ahead, so they came back eight hours late. They are now correct.

What to do: If you stored or compared these values, expect them to move earlier by eight hours for affected plans.