# Register event visitors with zero credentials (/use-cases/event-visitor-passes)

Submit visitor-pass applications from your event site, coworking space, or tourism platform — no API key required.



You host a conference in Próspera, run a coworking space, or operate a travel platform, and you want attendees to request their Próspera visitor pass directly from your own registration flow.

**API credential:** none. [POST visitor\_pass\_applications](/reference/post-visitor-pass-applications) requires a fresh **Cloudflare Turnstile** verification token for every submission. Before integrating, arrange an approved hostname and the portal's public Turnstile widget key with the Próspera team. Alternatively, direct attendees to the portal visitor-pass form. Do not use an unrelated Turnstile widget or request the server secret.

## The flow [#the-flow]

Collect the visitor's details and render the approved Turnstile widget with action `visitor-pass`. Include the token returned by its success callback:

```bash
curl -s -X POST https://portal.eprospera.com/api/v1/visitor_pass_applications \
  -H "Content-Type: application/json" \
  -d '{
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "1990-01-02",
    "email": "jane@example.com",
    "signature": "<canvas PNG data URL>",
    "turnstileToken": "<fresh token from the approved widget>",
    "consentToBackgroundCheck": true,
    "referralSource": "Acme Conference 2026"
  }'
```

The applicant receives follow-up steps by email; your platform's job ends at submission. Use `referralSource` to identify your event or venue — it's how arrivals get attributed to you.

The server verifies the token before processing the application. Tokens expire after five minutes and are single-use; reset the widget after an attempted submission, including a failed one. Missing, rejected, expired, reused, wrong-action, or wrong-hostname tokens return `400`. If verification is unavailable, the API returns `503` without processing the application. The existing IP rate limit also applies (`429`).

<Callout title="Consent is required" type="warn">
  `consentToBackgroundCheck` must be `true` and the signature must be the
  applicant's own. Present the consent language to the visitor yourself — don't
  pre-tick it.
</Callout>

## Pair it with verification [#pair-it-with-verification]

If your venue also gates access for existing residents, combine this with [RPN verification](/use-cases/verify-residents) using a standard API key: visitors go through the pass flow, residents get verified in one call.

## What this API does not do [#what-this-api-does-not-do]

* No status polling for visitor passes — the applicant is contacted by email; there is no read-back endpoint.
* No bulk submission; one application per visitor.

## Next steps [#next-steps]

* [POST visitor\_pass\_applications](/reference/post-visitor-pass-applications) — full request schema
* [Getting started](/getting-started) — if you outgrow the no-auth surface