> ## Documentation Index > Fetch the complete documentation index at: https://api-docs.helpyousponsor.com/llms.txt > Use this file to discover all available pages before exploring further. # Look up checkout donors by email > Checks whether a donor email already exists for the client before public checkout continues. The controller validates email, verifies the program belongs to the client, then returns lightweight donor choices for account selection or passwordless verification. The legacy alias `/frontend/checkout_email_lookup/{client_id}/{program_id}` is routed to the same method. ## OpenAPI ````yaml post /frontend/checkout/email_lookup/{client_id}/{program_id} openapi: 3.0.0 info: title: Gratona API description: >- REST API for the Gratona fundraising platform, including donor, donation, sponsorship, program, event, and integration workflows. Endpoints are organized by tag. Most endpoints require either a Passport bearer token or an issued API key — see the Security Schemes section. contact: name: Gratona Engineering url: https://gratona.com email: devs@gratona.com version: 1.0.0 servers: - url: https://api.gratona.com/v1 description: Server Version 1.0.0 security: [] tags: - name: Auth description: >- Login, signup, logout, password reset, and email verification for admin users and donors. - name: Donors description: >- Donor records: CRUD, profile fields, household linkage, search, filters, merge, and duplicate detection. - name: Donations description: >- Individual donation records, recurring commitments, soft credits, refunds, designations, and exports. - name: Sponsorships description: >- Donor-to-entity sponsorship relationships, lifecycle transitions, and sponsorship-specific filters. - name: Entities description: >- Recipient records (children, families, projects, animals, etc.), their status, and entity-level fields. - name: Programs description: >- Program / campaign configuration: hierarchy, settings, and program-level metadata. - name: Forms description: >- Custom form builder (HysForm), form fields, standardized donor fields, and field migrations. - name: Trips description: >- Mission-trip management: trips, participants, budgets, tasks, e-signatures, fundraising milestones, and background checks. - name: Communications description: >- Email templates, SMS, newsletters, donor email manager, and per-donor notes. - name: Payments description: >- Payment-gateway management (Stripe, PayPal, Flutterwave, QuickBooks). Excludes inbound webhooks — see the Webhooks tag. - name: Reports description: Dashboards, analytics, scheduled reports, and exports. - name: Admin description: >- Client-account administration: users, groups/permissions, settings, integrations, and account lifecycle. - name: Donor Portal description: >- Endpoints consumed by the donor-facing portal (donor login, dashboard, donation history, messages). - name: Recipient Portal description: Endpoints consumed by the recipient-facing portal. - name: Public description: >- Unauthenticated public endpoints: donor signup, public trip pages, peer-to-peer campaigns, public checkout. - name: Webhooks description: >- Inbound webhooks from third parties (Stripe, PayPal, Flutterwave, Checkr, DropboxSign). Annotated minimally for reference; payload shapes are owned by the upstream provider. - name: Client description: Client - name: Email Settings description: Email Settings - name: Admin Dashboard description: Admin Dashboard - name: Historical Archived Updates description: Historical Archived Updates - name: Team & access description: Team & access - name: Files description: Files - name: Wrapped description: Wrapped - name: Donor SignUp description: Donor SignUp - name: Frontend description: Frontend - name: User description: User paths: /frontend/checkout/email_lookup/{client_id}/{program_id}: post: tags: - Public summary: Look up checkout donors by email description: >- Checks whether a donor email already exists for the client before public checkout continues. The controller validates email, verifies the program belongs to the client, then returns lightweight donor choices for account selection or passwordless verification. The legacy alias `/frontend/checkout_email_lookup/{client_id}/{program_id}` is routed to the same method. operationId: lookupCheckoutDonorsByEmail parameters: - name: client_id in: path description: Client id that scopes the program and donor lookup. required: true schema: type: integer example: 207 - name: program_id in: path description: >- Program id that must belong to the client before donor lookup is allowed. required: true schema: type: integer example: 11 requestBody: description: Email address entered during checkout. required: true content: application/json: schema: required: - email properties: email: description: >- Email to normalize and look up for this client. Validator rule: `required|email`. type: string format: email example: jane@example.org type: object responses: '200': description: Checkout donor lookup result. content: application/json: schema: properties: status: type: string example: success data: properties: email: type: string format: email example: jane@example.org exists: type: boolean example: true count: type: integer example: 1 donors: type: array items: properties: id: type: integer example: 12345 email: type: string format: email example: jane@example.org username: type: string example: janedonor nullable: true display_name: type: string example: Jane Donor type: type: string example: INDIVIDUAL nullable: true type: object type: object type: object '404': description: Program was not found for this client. content: application/json: schema: $ref: '#/components/schemas/NotFoundResponse' '422': description: Email validation failed. content: application/json: schema: $ref: '#/components/schemas/ValidationErrorResponse' security: [] components: schemas: NotFoundResponse: title: NotFoundResponse description: >- Returned with HTTP 404 when a resource lookup misses (typically because the id doesn't exist OR is scoped to a different `client_id`). Note: many endpoints intentionally collapse 'not found' and 'forbidden' into a single 404 to avoid leaking which records exist in another tenant. required: - message properties: message: description: >- Human-readable message. Often a more specific string like `Donor not found` or `Trip not found`. type: string example: Not Found status: type: string example: error type: object ValidationErrorResponse: title: ValidationErrorResponse description: >- Returned with HTTP 422 when `Validator::make($data, $rules)` fails. The `errors` map is keyed by the failing field name; each value is an array of human-readable error messages for that field. Most controllers also include a top-level `status: error`. required: - errors properties: errors: description: >- Map of field name to array of validator error messages. Example: `{email: [The email field is required.], amount: [The amount must be a number.]}`. type: object additionalProperties: type: array items: type: string status: description: Always the literal string `error`. type: string example: error message: description: >- Optional summary message — present on some endpoints, absent on others. type: string example: The given data was invalid. nullable: true type: object ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.