# Production Access Requirements for Public API

## Overview

To ensure optimal performance and stability for all customers, we require a comprehensive testing period before granting production access to our Public API. This process helps us validate your integration patterns and ensures your application can safely and efficiently operate in a production environment.

## Testing Requirements

### Volume Testing

- Minimum 1,000 API calls across your intended production endpoints
- Test with realistic data volumes that match your expected production usage
- Demonstrate consistent performance across different endpoint types


### Endpoint Coverage

List the specific endpoints you plan to use in production, including but not limited to:

**Core Data Endpoints:**

- `/v1/patients` - Patient data management
- `/v1/appointments` - Appointment scheduling and retrieval
- `/v1/transactions` - Financial transaction data
- `/v1/events` - System events and activities
- `/v1/visits` - Patient visit records
- `/v1/documents` - Document management
- `/v1/providers` - Provider information
- `/v1/procedures` - Procedure data


**Specialized Endpoints:**

- `/v1/patientprocedures` - Patient procedure tracking
- `/v1/txcases` - Treatment case management
- `/v1/patientrecares` - Patient recall management
- `/v1/clinicalnotes` - Clinical documentation


### Pagination Testing Requirements

**Critical:** Demonstrate proper pagination implementation using `lastModified` and `lastId` parameters for efficient data retrieval. Example Pagination Pattern - Initial Request:

```
GET /api/v1/patients?filter=lastModified>2024-01-01T00:00:00Z&pageSize=100
```

**Subsequent Requests:**

```
GET /api/v1/patients?filter=lastModified>2024-01-01T00:00:00Z&lastId=12345&pageSize=100
```

Pagination is the most commonly misused functionality in the API, and production access will not be granted until correct usage is demonstrated. If a pattern of misuse is identified in production, API access may be temporarily disabled until correct pagination behavior is verified.

Offset-based pagination is discouraged for large datasets and should not be used for ongoing data synchronization.

### Why This Pattern Matters

- **Performance:** Using `lastId` with date filters provides the most efficient pagination
- **Consistency:** Ensures you don't miss or duplicate records during data synchronization
- **Scalability:** Essential for handling large datasets in production


### Testing Scenarios

**1. Data Synchronization Testing**

- Test incremental data retrieval using `lastModified` filters
- Verify pagination works correctly across large datasets
- Ensure no data gaps or duplicates in paginated results
- For continuous or near real-time synchronization, customers should use the Stream API instead of repeated bulk GET requests.


**2. Error Handling**

- Test rate limiting responses (429 status codes)
- Handle authentication failures (401/403)
- Manage timeout scenarios (408)


**3. Filter Combinations**

- Test complex filter combinations
- Validate date range filtering
- Test organization-specific data access


## Required Documentation

Please provide:

1. **Integration Architecture:** How your system will consume the API
2. **Expected Call Volume:** Daily/hourly API call estimates
3. **Monitoring Acknowledgement:** Client responsibility for call volume and error monitoring
4. **Peak Usage Patterns:** When you expect highest API usage
5. **Data Requirements:** Which endpoints and data fields you need
6. **Error Handling Strategy:** How you'll handle API errors and retries


## Performance Expectations

- **Response Times:** Most endpoints respond within 200-500ms
- **Rate Limits:** Vary by endpoint. Responses include a `Rate-Limiting-Remaining` header and, when exceeded, a 429 status code with a `Retry-After` header.
- **Pagination:** Use `lastId` for optimal performance with large datasets
- **Concurrent Requests:** Test with your expected concurrent request volume


## Next Steps

1. **Sandbox Testing:** Complete your 1,000+ call testing in our sandbox environment
2. **Documentation Review:** Ensure your integration follows our pagination best practices
3. **Performance Validation:** Demonstrate consistent, reliable API usage patterns
4. **Production Access:** Upon successful testing, verification of requests will be made by our API team, we'll provision your production credentials


## Support Resources

- **API Documentation:** Complete endpoint documentation available in our developer portal
- **Pagination Guide:** Detailed pagination examples and best practices
- **Rate Limit Information:** Endpoint-specific rate limiting details
- **Support Team:** Available to assist with integration questions