A

AfriRoute

Developer Portal

public api
Sign in
SDKs

Install an official client and move from raw requests to stable integration code

SDK pages should make adoption easier, not hide the basics. Show package install commands first, then a single working request, then the operational paths developers need after the first successful response.

SDK adoption path

Use the language your team already ships, not a hand-rolled wrapper

Official SDKs should mirror the public API clearly: install the package, configure the same key you used in quickstart, send one request, then extend into webhooks, retries, and operational monitoring only after the base path works.

Three-step path

1

Install the client

Start with an official package instead of writing request wrappers around raw fetch or curl calls.

2

Configure one key

Use the same API key and tenant flow already shown in quickstart so the SDK path matches the HTTP path.

3

Ship one request

Make one send call, inspect the response, then add retries, delivery events, and environment separation.

Supported SDKs

Node.js

TypeScript / JavaScript

npm install afriroute-sdk

Python

Python

pip install afriroute-sdk

Go

Go

go get afriroute.ai/sdk-go

Java

Java

mvn install afriroute-sdk

PHP

PHP

composer require afriroute/sdk

C#

C#

dotnet add package AfriRoute.SDK

What this page should answer

Install commands developers can copy immediately

Keep package names, registries, and quick install commands visible before deeper SDK docs.

Examples aligned with quickstart and messaging

The first request should look the same whether a team starts from curl, explorer, Postman, or an SDK.

A clean path into production behavior

Guide teams from install into auth setup, error handling, webhook verification, and usage visibility.

SDK baseline

What the first request should preserve

Same endpoint shape as the HTTP docs
Same API key and tenant configuration path
Same delivery and webhook behavior after the request returns