API Lifecycle & Versioning

The public REST API is currently served under the versioned /api/v1 path:

Environment	Base URL
Production	https://api.payscribe.ng/api/v1
Sandbox	https://sandbox.payscribe.ng/api/v1

Use the versioned URL in every integration. Do not construct endpoints by assuming an unversioned route will remain available.

Change policy

Changes that only add optional fields, event types, or endpoints are treated as non-breaking. Your integration must tolerate unknown JSON fields and webhook events so these additions do not interrupt processing.

Changes that remove or rename a field, change a field type or validation rule, alter authentication, or change a webhook payload signature are breaking changes. Breaking changes require a new API version or a published migration path.

Changelog and migrations

Product and documentation changes are published in the Changelog. When a change affects an integration, the entry should state:

• the affected endpoints and environments;
• whether the change is breaking or non-breaking;
• the effective date and any deprecation date;
• required customer action; and
• a migration or rollback path.

Before upgrading an SDK or adopting a new API capability, run the relevant sandbox test matrix and deploy behind a controlled release where possible.

Deprecations

When an endpoint or field is scheduled for retirement, Payscribe will document the replacement, the migration steps, and the retirement date in the Changelog and the affected reference page. Subscribe to operational notices through the dashboard.

Compatibility requirements

• Ignore response and event fields you do not use.
• Use event names—not inferred payload shapes—to route webhook handling.
• Preserve your request ref and webhook event IDs in logs for support and reconciliation.
• Do not rely on undocumented response ordering, timing, or internal identifiers.