Getting Started

  • Introduction
  • Concepts & Glossary
  • Quickstart
  • Authentication

API Reference

  • Endpoints
  • Error Handling
  • Versioning

Guides

  • Code Examples
  • FHIR R4 Integration
  • Integration Patterns
  • Going to Production

Medical Content

  • Knowledge Base

Tools

  • Interactive Sandbox
  • API Status

Resources

  • FAQ
  • Changelog
  • Support
DevelopersGetting StartedAuthentication

Loading documentation…

QuickstartEndpoints
PearMedica Logo

The clinical intelligence layer built for African healthcare. Empowering providers with AI-driven triage and decision support.

Product

  • Symptom Assessment
  • Triage Engine
  • Decision Support
  • Pricing

Developers

  • Documentation
  • API Reference
  • Quickstart Guide
  • Code Examples

Company

  • About Us
  • Contact
  • Blog
  • Careers

Legal

  • Privacy Policy
  • Terms of Service
  • Security & Compliance
  • NDPA Compliance
NDPA 2023
AES-256 Encryption
Audit Logging

© 2026 PearMedica. All rights reserved.

Status

Authentication

All PearMedica API requests require authentication via API keys. This guide covers key management, rate limiting, and security best practices.

API Key Format

PearMedica issues two types of API keys, distinguished by their prefix:

PrefixEnvironmentUsage
sk_live_ProductionLive patient assessments. Usage is metered and billed.
sk_test_DevelopmentSandbox testing. Returns mock data, not billed.

Using Your API Key

Include your API key in the Authorization header of every request:

http
Authorization: Bearer sk_live_your_api_key_here

Security Best Practices

  • Never expose API keys in client-side code (browsers, mobile apps)
  • Store keys in environment variables, not in source code
  • Use sk_test_ keys for development and testing
  • Rotate keys immediately if you suspect they've been compromised
  • Use separate keys for each environment (staging, production)

What Your Key Unlocks

Every API key gives you full access to the entire PearMedica platform. There are no endpoint-specific restrictions — your single key works across all endpoints.

EndpointPurposeBilling
POST /v1/assessAI symptom assessment✦ Billable
POST /v1/parseNLP symptom extractionFree
GET /v1/symptomsList symptoms catalogueFree
GET /v1/risk-factorsList risk factorsFree
GET /v1/lab-testsList lab testsFree
GET /v1/conditions/{id}Condition detailsFree
GET /v1/conditions/{id}/educationPatient educationFree
GET /v1/searchKnowledge searchFree
GET /v1/rationaleAssessment reasoningFree
GET /v1/usageUsage statisticsFree
GET /v1/healthHealth check (no auth)Free
POST /v1/fhir/assessFHIR R4 assessment✦ Billable
GET /v1/fhir/metadataFHIR capability statementFree

Only POST /v1/assess and POST /v1/fhir/assess count toward your monthly assessment quota. All other endpoints are free and unlimited.

Key Management

Manage your API keys from the Dashboard → API Keys page. Available actions:

Create Key

Generate a new API key with a descriptive label. The full key is shown once — save it immediately.

Rotate Key

Generates a new key and invalidates the old one. Use POST /v1/keys/rotate or the dashboard.

Revoke Key

Permanently disables a key. All requests using it will receive 401 Unauthorized.

View Usage

See per-key usage metrics: total requests, last used timestamp, and rate limit status.

Rate Limiting

All API keys have a default rate limit of 100 requests per minute using a sliding window algorithm. Rate limit headers are included in every response:

http
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1709193600
TierRate LimitMonthly Quota
Pilot100 req/min200 assessments included
Professional100 req/min2,500 included + ₦100/additional
EnterpriseCustomCustom — contact sales

If you exceed the rate limit, you'll receive a 429 Too Many Requests response. Implement exponential backoff to handle this gracefully.

Response Headers

HeaderDescription
X-RateLimit-LimitMaximum requests allowed per window (e.g., 100).
X-RateLimit-RemainingRequests remaining in the current window.
X-RateLimit-ResetUnix timestamp (seconds) when the window resets.
Retry-AfterSeconds to wait before retrying (only present on 429 responses).

Handling Rate Limits

javascript
async function fetchWithRetry(url, options, maxRetries = 3) {
const baseDelayMs = 1000;
for (let attempt = 0; attempt < maxRetries; attempt++) {
const res = await fetch(url, options);
if (res.status !== 429) return res;
// Use server-provided Retry-After directly when available;
// only fall back to exponential backoff when absent or invalid.
const retryAfterRaw = parseInt(res.headers.get('Retry-After') || '', 10);
const backoff = Number.isFinite(retryAfterRaw) && retryAfterRaw > 0
? retryAfterRaw * 1000
: baseDelayMs * Math.pow(2, attempt);
await new Promise(r => setTimeout(r, backoff));
}
throw new Error('Rate limit exceeded after max retries');
}

Idempotency

Coming Soon

For billable POST endpoints, include an Idempotency-Key header to prevent duplicate processing on network retries. This is critical in Africa's unreliable network environment.

javascript
const response = await fetch('https://api.pearmedica.com/v1/assess', {
method: 'POST',
headers: {
'Authorization': 'Bearer sk_live_your_key',
'Content-Type': 'application/json',
'Idempotency-Key': 'a1b2c3d4-e5f6-7890-abcd-ef1234567890', // UUID
},
body: JSON.stringify({ patient, evidence }),
});
// If you retry with the same Idempotency-Key, you'll get
// the cached response — no duplicate assessment or billing.

Planned Behaviour

  • • Cached responses are stored for 24 hours per key
  • • Duplicate key with same body → returns cached response (no re-billing)
  • • Duplicate key with different body → 409 Conflict
  • • No header provided → request processed normally (no idempotency)

Available today: Assessment sessions already have natural idempotency via the interview_id field. Sending the same interview_id continues an existing session rather than creating a duplicate.

Next Steps

Make your first API callExplore the full API Reference