Skip to content

SDKs

The API is plain HTTP and JSON, so you can integrate with nothing but an HTTP client. Generated SDKs exist for eight targets if you would rather start from typed models.

What is generated

Every one is produced from the same API description this site documents, on every release. None is hand-written, and none adds behavior beyond the endpoints.

TargetNotes
C#.NET client
JavaGradle, Maven and sbt builds
JavaScriptBrowser and Node
KotlinGradle
PHP—
Perl—
SwiftSwift Package Manager, CocoaPods and Carthage
TypeScriptaxios-based

There is also a C# ASP.NET Core server stub — interfaces and models for a service that implements this API, not a client for calling it. Useful if you are building a mock or a conformance harness.

Ask your implementation contact for access; the generated packages are not published to public registries.

When to use one, and when not to

Use an SDK when you want typed request and response models, and your language is on the list.

Call the API directly when any of these is true:

  • Your language is not on the list.
  • You want to control retries, timeouts and connection reuse yourself. The generated clients take whatever the generator's defaults are.
  • You are sending a handful of requests. Seven endpoints cover almost every integration, and wiring an HTTP client to them is a small job.

There is no feature in an SDK that the HTTP API does not have. The choice is about ergonomics, not capability.

Two things a generated client will not catch

Because the clients are generated from the description, they inherit its gaps.

The error enum is incomplete. The description declares seven error_code values; twelve can reach you. Handle an unrecognized code by falling back on the HTTP status rather than throwing. See API response codes.

Some rules are enforced only by the gateway. The recurring-payment rules are the clearest case: the schema carries no conditional validation, so a generated client will happily build a request the API then rejects with 400. See Recurring payments.

Regenerating against a new version

Read the changelog before you upgrade. It is organized by what you have to do about each change — Breaking first, then Corrected, which is where the API never behaved the way the old document claimed.

A Corrected entry is the one to read closely. Nothing in the API changed, so nothing will fail at build time; your code may simply have been written against a description that was wrong.

Calling the API without an SDK

Every request needs two headers, and content type on anything with a body.

POST /v1/transactions HTTP/1.1
Host: https://api.dev.paradisegateway.net
Content-Type: application/json
Api-Key: $d48045e5-f017-4633-a5e7-4efb56f70afa
Client-Id: CLIENT-01KFDKXMQ637EKEAY410MSQSXB

Authentication covers both headers and the third one resellers use. Every page in this documentation carries a runnable sample for its endpoint, generated from the same description the SDKs are, so the shapes there are always current.

Next steps