API Concepts

This section explains the core technical concepts and conventions used across all YAPU APIs. If you are new to integrating with YAPU, read this page before moving to authentication or technical specifications.

Architecture overview

YAPU APIs follow REST (Representational State Transfer) architecture. This means:

• APIs are organized around resources and accessed via standard HTTP verbs (GET, POST, etc.)
• Every request and response uses JSON as the data format
• All communication happens over HTTPS — no exceptions
• Each API call is a single JSON request, not batched or streamed

This makes YAPU APIs compatible with any modern programming language or platform that can make HTTPS requests and parse JSON.

Transport and security requirements

HTTPS only

All YAPU API communication must happen over HTTPS. Requests sent over plain HTTP will not be accepted. There are no exceptions to this requirement.

Dynamic IP communication

YAPU supports dynamic IP communication. This means the IP address of your integration does not need to be registered or whitelisted in advance.

:::warning Important limitation YAPU does not support static IP communication. If your infrastructure requires a fixed, whitelisted IP address to reach external services, this must be discussed with your YAPU contact before the specification phase begins. :::

Request and response format

Request structure

Every YAPU API call is made as a single JSON request. There are no multi-part requests or file uploads in standard API bundles.

Requests follow standard HTTPS conventions:

• A defined HTTP verb (e.g., POST, GET)
• Required request headers, including authentication
• A JSON body where applicable

Exact request structures are defined per API bundle in the technical documentation provided during the specification phase.

Response structure

YAPU returns responses as JSON. Response data is generally provided as string values — it is the client's responsibility to convert these strings into the appropriate data types for their own systems.

note

The conversion of outgoing YAPU data from string format into your own data model is a client responsibility and should be planned into your development scope.

HTTP status codes

YAPU APIs use standard HTTP status codes to communicate the result of a request:

Code	Meaning
200 OK	Request succeeded
201 Created	Resource created successfully
400 Bad Request	Request was malformed or missing required fields
401 Unauthorized	Authentication failed or token is missing
403 Forbidden	Authenticated but not authorized for this action
404 Not Found	Resource does not exist
422 Unprocessable Entity	Request was valid but could not be processed
500 Internal Server Error	Unexpected error on the YAPU side

Data format conventions

Incoming data (client to YAPU)

Data sent from your system to YAPU must follow YAPU-specific formats. These formats are defined for each API bundle in the technical documentation provided during the specification phase.

Not following the correct format will result in a failed request. YAPU does not silently transform or reformat incoming data.

Outgoing data (YAPU to client)

Data returned by YAPU is provided as string values. Your system is responsible for interpreting and converting this data into the formats your application requires.

Environments

YAPU provides two environments for integration:

Environment	Purpose
Staging	Integration development and testing — not for production use
Production	Live system — only used after mutual testing in staging is complete

Environment-specific URLs and credentials are provided by your YAPU contact during the specification phase and are not published in this portal.

info

Always complete staging testing before deploying to production. See Testing & Go-Live for the full testing process.

Summary

Concept	Value
Architecture	REST
Data format	JSON
Transport	HTTPS only
IP communication	Dynamic (static IP not supported)
Request type	Single JSON request per call
Outgoing data type	String (client converts)
Incoming data format	YAPU-specific (defined per bundle)
HTTP status codes	Standard