Go live Checklist

• Integration Certification Guide – Hoppa API

• This guide outlines the certification process required to validate your integration with the Elfe API prior to going live in the production environment. As part of this process, partners are expected to complete a series of structured test scenarios and submit relevant logs for review by the Hoppa technical team.

• The objective is to ensure correct handling of bookings, data transmission, disclaimer logic, and voucher generation as per Hoppa’s operational standards.

• ✅ Hoppa Partner API – Go-Live Checklist for Integration Partners

1. Authentication Setup

• Partner has received API Key from Hoppa and validated it in sandbox

• API requests use the correct authentication method (e.g., Bearer token).

• Token referesh or renewal flow is implemented (if applicable).

• Authorization header (`Authorization: Bearer `) is included in all requests.

• Secure storage of API credentials is ensured (e.g., environment variables).

2. Environment Configuration

• Sandbox base URL (``) used for integration testing.

• Production base URL (` ) configured for go-live.

• No sandbox keys or URLs exist in the production environment.

• Environment variables or configuration toggles are used for environment switching.

• Partner confirms separation between test and live booking workflows.

3. Functional API Testing

• Partner has received API Key from Hoppa and validated it in sandbox.

• Partner /ride-quotes` tested with various parameters including serviceType, time, location, passengers, and luggage.

• `Partner /confirm` books ride and returns a valid booking ID, with all necessary data.

• `Partner /cancel` cancels rides and returns valid status response (including policy-driven cases).

• `Partner GET /ride-status` fetches booking updates in real time with correct statuses.

4. Additional Services Validation

• Partner has enabled and tested support for Child Seat types (if enabled in their integration scope).

• Meet & Greet option is configurable and behaves as expected.

• Luggage options (standard/extra) are correctly submitted and affect pricing if applicable.

5. Vehicle & City Coverage

• Coverage tested with `GET /coverage` and cities validated for partner’s use case.

• All internal vehicle categories mapped to Hoppa’s vehicle codes and names.

• Graceful fallback or notification exists for unsupported vehicles or locations.

6. Pricing, Booking Fee & Commission

• Booking fee retrieved from quote response and displayed correctly to users for train rides.

• Price breakdown includes base fare, taxes, fees, and surcharges.

• Currency code (e.g., INR, USD) shown properly with formatting rules applied.

7. Webhooks & Notifications

• Webhook URL registered with Hoppa if real-time notifications are used.

• Webhooks tested for all events: Booking confirmed, Driver assigned, Ride started, Ride completed, Cancellation.

• Partner systems acknowledge and log incoming webhooks.

• Duplicate or retry webhook deliveries handled via idempotency logic.

8. Date/Time Formatting & Timezones

• All time values sent/received in ISO 8601 format (e.g., `2025-08-01T14:30:00Z`).

• Partner handles pickup/dropoff in user’s local timezone.

• Internal systems convert time correctly for UI and processing flows.

9. Error Handling & Stability

• Partner handles all Hoppa API response codes (2xx, 4xx, 5xx).

• 400-499 errors provide user-friendly responses (e.g., invalid location, unavailable vehicle).

• Retry logic in place for temporary issues (e.g., 429 rate limit, 500 server error).

• Detailed error logs captured and accessible by developer or support teams.

10. Logging & Monitoring

• Partner logs all API requests/responses with status, timestamps, and transaction IDs.

• API keys, tokens, and sensitive user information are excluded from logs.

• Alerts or monitoring dashboards are set up to detect failure spikes or anomalies.

11. Documentation & Developer Support

• Partner has fully reviewed [Theneo API Docs](https://app.theneo.io/hoppa-docs/hoppa-partner-api-multi-modal/about-hoppa-apis).

• Internal documentation prepared for tech team reference and troubleshooting.

• Escalation contacts and Hoppa support team details are stored securely.

12. UAT Sign-off

• All critical use cases tested and verified in sandbox: Quote, Book, Cancel, Status.

• Edge cases tested: unsupported areas, invalid inputs, cancellation deadlines.

• QA team or stakeholder has approved readiness for production.

13. Final Go-Live Validation

• Production keys configured in secure environment.

• Smoke test run in production for real bookings.

• Live monitoring confirmed with alerts active.

• Final handover or launch confirmation shared with Hoppa support

---

Questions?

For any certification or integration-related inquiries, contact: