Overview
All Parchment Health API endpoints follow a consistent response structure to ensure predictability and ease of integration. Our responses comply with industry standards including RFC 7807 for error handling.Response Structure
Success Response Format
All successful API responses follow this structure:Error Response Format (RFC 7807)
All error responses follow the RFC 7807 Problem Details standard:HTTP Status Codes
Success Codes
| Code | Status | Usage |
|---|---|---|
200 | OK | Successful GET, PUT, PATCH operations |
201 | Created | Successful POST operations (resource creation) |
202 | Accepted | Request accepted for processing (e.g., conflicts found) |
204 | No Content | Successful DELETE operations |
Error Codes
| Code | Status | Usage |
|---|---|---|
400 | Bad Request | Invalid request data or parameters |
401 | Unauthorized | Authentication required or failed |
403 | Forbidden | Authorization failed (insufficient permissions) |
404 | Not Found | Requested resource does not exist |
409 | Conflict | Business logic conflict (e.g., duplicate IDs) |
422 | Unprocessable Entity | Validation errors in request data |
429 | Too Many Requests | Rate limiting exceeded |
500 | Internal Server Error | Unexpected server error |
503 | Service Unavailable | External service temporarily unavailable |
Response Fields
Core Fields
| Field | Type | Description |
|---|---|---|
success | boolean | Indicates if the request was successful |
statusCode | number | HTTP status code |
message | string | Human-readable message (success responses) |
data | object | Response payload (success responses) |
error | object | Error details (error responses) |
timestamp | string | ISO 8601 timestamp of the response |
requestId | string | Unique identifier for request tracing |
Optional Fields
| Field | Type | Description |
|---|---|---|
pagination | object | Pagination information for list operations |
Pagination Object Fields
| Field | Type | Description |
|---|---|---|
count | number | Number of items returned in the current page |
hasNext | boolean | Whether more items are available on subsequent pages |
limit | number | Maximum number of items per page (as requested) |
offset | number | Starting position of the current page (zero-based) |
lastKey | string|null | Opaque cursor for fetching the next page. Use this value as the lastKey query parameter for the next request. If null, no more pages are available |
Error Object Fields
| Field | Type | Description |
|---|---|---|
type | string | URI identifying the problem type |
title | string | Human-readable summary of the problem |
detail | string | Human-readable explanation |
instance | string | URI reference to the specific occurrence |
validation | array | Field-level validation errors (422 responses) |
Error Types
Standard Error Types
| Error Type | Description |
|---|---|
invalid-request | General invalid request format |
missing-required-field | Required field not provided |
invalid-format | Data format validation failed |
authentication-required | Authentication token missing |
invalid-token | Authentication token invalid |
token-expired | Authentication token expired |
insufficient-scope | Missing required permissions |
access-denied | Access to resource denied |
resource-not-found | General resource not found |
patient-not-found | Specific patient not found |
resource-conflict | General resource conflict |
partner-patient-id-conflict | Partner patient ID already exists |
validation-error | Request validation failed |
business-rule-violation | Business logic constraint violated |
rate-limit-exceeded | Too many requests |
internal-error | Unexpected server error |
service-unavailable | External service unavailable |
Response Examples
Create Patient Success (201)
Get Patient Success (200)
List Patients Success (200)
Validation Error (422)
Unauthorized Error (401)
Partner Patient ID Conflict (409)
Patient Not Found (404)
Internal Server Error (500)
Request Tracing
Every response includes a uniquerequestId that can be used for:
- Debugging: Reference this ID when reporting issues
- Logging: Correlate requests across different systems
- Monitoring: Track request flow through the system
req_1705312200000_abc123
API Versioning
The API version information is tracked internally for compatibility purposes, allowing for:- Backward Compatibility: Maintain support for older integrations
- Feature Detection: Identify available features based on version
- Migration Planning: Plan upgrades to newer API versions
Pagination Usage
When working with paginated endpoints, use thelastKey field to navigate through pages:
Making Paginated Requests
Pagination Best Practices
- Always check
hasNextbefore requesting the next page - Use
lastKeyfor cursor-based pagination when available - Fall back to
offsetfor offset-based pagination when needed - URL encode
lastKeyvalues when using as query parameters - Handle
nulllastKey as indication of no more pages
Best Practices
Error Handling
- Always check the
successfield to determine if the request succeeded - Use
statusCodefor programmatic handling of different scenarios - Display
error.detailto users for human-readable error messages - Log
requestIdfor debugging and support requests - Handle validation errors by checking the
error.validationarray
Integration Tips
- Store
requestIdin your logs for easier debugging - Implement retry logic for 5xx errors with exponential backoff
- Cache successful responses when appropriate to reduce API calls
- Monitor response times for performance tracking
- Validate API version compatibility when integrating
Migration Guide
From Legacy Responses
If you’re migrating from the legacy response format:- Update success checks: Use
response.successinstead of checkingstatusCode < 400 - Extract data: Access response data from
response.datainstead of the root - Handle errors: Use
response.errorobject instead ofresponse.message - Add request tracing: Store
response.requestIdfor debugging

