OpenAPI and Postman Pack

Machine-readable contracts and executable test assets.

Download DOCX Download full Openapi-assets/Postman ZIP

YCMT EU Partner Developer OpenAPI and Postman Pack Guide

Partner developer tooling pack | Version 1.0 | YCMT EU

Partner-safe scope This guide explains how to use the YCMT EU partner-facing OpenAPI and Postman assets. It is limited to the API interface, testing workflow, placeholders, and versioning rules. It does not describe YCMT internal implementation, internal systems, internal identifiers, or internal risk logic.

Field	Value
Document	`60_YCMT_EU_PartnerDev_OpenAPI_And_Postman_Pack_Guide_v1_0.docx`
Audience	Partner developers, partner QA engineers, partner technical leads
Perimeter	YCMT EU only
Status	Draft for partner onboarding use
Confidentiality	Partner-facing under onboarding/NDA controls
Related pack files	Getting Started; API Guide; Flows Guide; Errors, Statuses and Retry Guide; Security and Signing Guide; Sandbox and Go-Live Guide

1. Purpose of this pack
2. Files included
3. How to use the OpenAPI files
4. How to use the Postman collection
5. Environment variables
6. Placeholder and secret handling
7. Testing sequence
8. Change management and changelog use
9. What this pack intentionally excludes
10. Quick troubleshooting checklist

1. Purpose of this pack

The OpenAPI and Postman Pack gives partner development teams a machine-readable and executable starting point for integrating with the YCMT EU APIs. It complements the human-readable Partner Developer guides.

Asset type	Use it for
OpenAPI YAML	Generating API clients, validating request/response shapes, reviewing endpoint paths and schemas.
Postman collection	Manual testing, onboarding demos, sandbox smoke tests, and QA evidence.
Postman environment	Separating sandbox variables from production variables.
Changelog	Tracking API version notices and integration-impacting changes.

2. Files included

File	Purpose
`60_YCMT_EU_PartnerDev_OpenAPI_Auth_v1_0.yaml`	Partner-facing Authentication API contract.
`60_YCMT_EU_PartnerDev_OpenAPI_Core_v1_0.yaml`	Partner-facing Customer-Context Core API contract.
`60_YCMT_EU_PartnerDev_Postman_Collection_v1_0.json`	Postman collection skeleton covering Auth and Core endpoints.
`60_YCMT_EU_PartnerDev_Postman_Environment_v1_0.json`	Environment variable template for sandbox usage.
`60_YCMT_EU_PartnerDev_API_Changelog_v1_0.md`	Version history and partner-facing change notice rules.
`README.md`	Brief folder-level file list and usage note.

3. How to use the OpenAPI files

Import the Auth and Core YAML files into your preferred OpenAPI tool.
Set the server URL to the sandbox base URL provided during YCMT onboarding.
Generate a client SDK only after confirming that your generator handles OpenAPI 3.1.0 correctly.
Review required headers and request bodies against the Partner Developer API Guide.
Keep generated clients tolerant of additional response fields so non-breaking additions do not break your app.

Authoritative reading order Use the OpenAPI files for schema and endpoint shape. Use the API Guide and Flows Guide for sequencing, customer journey context, and practical examples. Use the Errors, Statuses and Retry Guide for resilience behaviour.

4. How to use the Postman collection

Import the Postman collection JSON file.
Import the Postman environment JSON file.
Select the YCMT EU sandbox environment.
Replace placeholder values with onboarding values provided by YCMT.
Run authentication calls first to obtain an access token.
Store the returned access token in the environment variable only for local sandbox testing.
Proceed through customer profile, KYC, beneficiary, quote, transfer, and status-polling tests.

5. Environment variables

Variable	Meaning	Handling rule
base_url	YCMT EU sandbox or production API base URL.	Use sandbox during testing. Do not mix sandbox and production.
api_key	Partner API access credential or onboarding-issued API key placeholder.	Treat as secret. Do not commit to source control.
access_token	Customer session token obtained after login.	Treat as secret. Do not share or log.
correlation_id	Trace identifier for support and debugging.	Generate per request or per flow as guided by YCMT.
idempotency_key	Unique key for safe retry of supported POST requests.	Generate per business action, not per blind retry.
quote_id	Quote identifier returned by quote flow.	Use only within the customer flow that produced it.
beneficiary_id	Beneficiary identifier returned by beneficiary flow.	Do not guess or reuse across customers.
transfer_id	Transfer identifier returned by transfer flow.	Use for status polling, confirmation, and cancellation where permitted.

6. Placeholder and secret handling

Replace placeholder values only in local or controlled secure environments.
Do not commit filled Postman environments to Git or shared repositories.
Do not paste live tokens, API keys, signing keys, or webhook secrets into tickets or chat tools.
Use separate sandbox and production environments.
Rotate any credential that may have been exposed.

Logging rule Partner systems must not log access tokens, refresh tokens, API keys, private keys, full identity documents, or unmasked payment details. Logs shared with YCMT for support should include timestamps, endpoint names, status codes, and correlation IDs only.

7. Testing sequence

Step	Use	Expected outcome
1	Authentication endpoints	Customer can register or log in and obtain a token.
2	Profile endpoint	Customer profile can be submitted/read as documented.
3	KYC session endpoint	Partner app can launch and handle the KYC flow.
4	Beneficiary endpoints	Partner app can create, list, retrieve, and archive beneficiaries where supported.
5	Quote and disclosure endpoints	Partner app can present quote and disclosure before acceptance.
6	Transfer endpoints	Partner app can submit, confirm where required, and poll status.
7	Negative scenarios	Partner app handles expired tokens, expired quotes, validation failures, and retryable failures safely.

8. Change management and changelog use

Read the changelog before upgrading generated clients or replacing Postman assets.
Treat path changes, required-field changes, enum meaning changes, authentication changes, and signing changes as potentially breaking.
Test in sandbox before production release.
Keep app parsing tolerant of optional response fields.
Notify YCMT before releasing changes that affect login, registration, KYC, quote acceptance, transfer submission, confirmation, funding, or webhook handling.

9. What this pack intentionally excludes

Excluded item	Reason
YCMT internal implementation	Partner developers need the interface, not internal systems.
Internal customer identifiers	Partners use only partner-visible identifiers returned by the API.
Internal risk logic and reason codes	YCMT controls regulated decisions and customer-safe disclosures.
Internal approval workflows	Operationally sensitive and not required for integration.
Production credentials	Issued separately through onboarding and activation controls.

10. Quick troubleshooting checklist

Symptom	Check first
Cannot connect	Confirm base_url, network access, and correct environment.
401 or unauthorised response	Confirm token is present, current, and belongs to the current customer session.
403 or permission-like response	Confirm production/sandbox credential, partner activation, and endpoint scope.
Validation error	Compare request body against OpenAPI schema and API Guide examples.
Duplicate or unexpected POST result	Check idempotency key reuse and retry behaviour.
Status does not progress	Poll according to the documented interval and escalate with correlation ID if outside expected behaviour.
Webhook not received	Check endpoint availability, TLS, firewall, and verification code.

Final developer reminder Use the OpenAPI files to understand the contract, the Postman collection to test the contract, and the human-readable guides to understand the correct customer journey. Do not infer internal YCMT behaviour from the tooling assets.