Documentation
AI Assistant Quick Start
A ready-to-paste prompt that lets an AI manage your event via the API.
Want an AI assistant to manage your event for you - add guests, issue tickets, edit speakers - without learning the API yourself? Generate a key and paste one block of text into your AI. That’s it.
How to use it
- In the console, open your event and go to Integrations → API Access.
- Choose the permissions the AI should have (per data type). Attendees and tickets start at No access because they hold personal data - turn them on only if the task genuinely needs them.
- Pick how long the key should last (1, 3, 6, 12 or 24 hours; 6 is the default) and press Generate AI key. Choose the shortest window that covers the job.
- Press Copy AI prompt. That copies the whole briefing - the instructions and your credentials, already filled in.
- Paste it into your AI assistant.
- Ask in plain language - e.g. “Create a speaker for Dr. Lee, CTO at Acme” or “List all speakers and flag any that are missing a photo”.
The assistant will confirm it can reach the API, then wait for your first instruction.
Note
Data and GDPR are your responsibility, and all use of the API is at your own risk. Guest and attendee records are personal data. Anything you send to an AI assistant leaves Event Vault and is processed under your AI provider’s terms, not ours. We do not recommend using AI for guest or attendee data. Before you start, review your AI provider’s data-processing clauses, and scope the key to the minimum it needs (for example, speakers only, or read-only).
Tip
Use a short-lived AI key for this - it expires on its own, and you can revoke it anytime from the API Access page. Only give the key the permissions the task needs, and never paste it into a tool you don’t trust. The copied prompt contains your API key, so treat it like a password.
Give the assistant network access
Some AI tools run in a sandbox that blocks outgoing internet requests by default. If yours does (for example, Claude’s Cowork), turn on outgoing access before running the prompt, and keep it locked to just this API:
- Enable Allow network egress (network access) in the tool’s capability settings.
- Under the domain allowlist, add
api.event-vault.comas an allowed domain. Allow only this domain rather than opening access to everything. - Start a new chat / session after changing these settings so they take effect. An existing chat may keep the old (blocked) network settings.
Without this, the assistant cannot reach the API and every call will fail.
Tip
Only allowlist the specific domain api.event-vault.com. Granting broad network access to an AI sandbox carries security risks, so keep the allowlist as narrow as possible and monitor what the assistant does.
The prompt
You normally do not need this page - the console’s Copy AI prompt button gives you this same text with your credentials already in it.
Use the copy below if you want to read the instructions first, adapt them, or brief an assistant that already has credentials. Where this version says “the .env file I provide”, the console’s version has your actual base URL, client id, event id and key filled in instead.
You are helping me manage an event through the Event Vault REST API. Use the
credentials from the .env file I provide (or that I paste below). Follow these
rules exactly.
CREDENTIALS (.env)
EVENTVAULT_API_BASE_URL - the API base URL
EVENTVAULT_CLIENT_ID - my client id
EVENTVAULT_EVENT_ID - the event id
EVENTVAULT_API_KEY - my secret API key (never print, log, or share it)
AUTHENTICATION - every request MUST include these HTTP headers:
x-api-key : <EVENTVAULT_API_KEY>
x-client-id : <EVENTVAULT_CLIENT_ID>
x-event-id : <EVENTVAULT_EVENT_ID>
x-timestamp : the current time in Unix MILLISECONDS, regenerated for every
request (it must be within 5 minutes of server time). Note
`date +%s%3N` is GNU-only - on macOS/BSD use
`python3 -c "import time;print(int(time.time()*1000))"`.
RULES
- Requests must actually reach api.event-vault.com. If your sandbox blocks outgoing
network access, either run on the local system terminal instead, or have me
allowlist api.event-vault.com in the sandbox settings. If every request fails to
connect, say so - do not keep retrying.
- Always check the HTTP status code, and always read the response body.
Read endpoints and the upsert endpoints return JSON. The guest/ticket endpoints
reply with a plain-text sentence on success, unless there is something to report -
then they return JSON too.
- A 400 returns {"error": "...", "details": [ ... ]}. The details array names the exact
field and problem. Read it and fix the field - do not retry the same body.
- A 403 has two very different causes. If the body is JSON, the key lacks that
permission/scope, has expired, or is for a different event - tell me, do not retry
blindly. If the body is HTML or mentions "error code: 1010", the request never
reached the API: Cloudflare blocked it for an unrecognised User-Agent. Send a normal
User-Agent header and try again.
- 429 means rate limited (300 requests/minute) - pause briefly and retry. Do not fan
out parallel requests; a steady sequence is fine.
- Before you create, remove, or delete anything, briefly tell me what you will do.
- Ask me for any details you need. Report the result after each action.
ENDPOINTS (all paths are relative to EVENTVAULT_API_BASE_URL)
Guests (permission: attendees):
POST /addGuest body: {"userEmail": required, "name", "role", "company",
"phone", "url", "country"}
POST /removeGuest body: {"userEmail"}
GET /getGuests -> array of guests. Identity fields come back BOTH inside
"vCardData" (FN/ROLE/ORG/TEL/URL) and mirrored on the top level
under the names addGuest takes (name/role/company/phone/url) -
use the top-level ones.
IMPORTANT: speakers that have an email also appear here, marked
"eventRole":"SPEAKER". Real attendees are the ones with no
eventRole - filter them out before counting attendees.
GET /getGuestCount -> {"guestCount", "guestCapacity", "maxAssignedUsers"}
Tickets (permission: tickets):
POST /addTicket body: {"userEmail", "ticketType", "sessionId" (optional)}
POST /removeTicket body: {"userEmail", "ticketType"}
GET /getGuestTickets?userEmail=... -> tickets for one guest
GET /getTicketsByType?ticketType=... -> tickets of one type
GET /getAllTickets -> all tickets
Tickets read back with "EMAIL"/"TIER" plus "userEmail"/"ticketType" mirrored on top -
use the mirrored ones. A ticket is keyed by ticketType + email, so calling /addTicket
twice with the same pair updates that ticket rather than issuing a second one.
Speakers (permission: speakers):
GET /getSpeakers -> array of speakers
POST /upsertSpeaker body: omit "speakerId" to CREATE (name required); include
"speakerId" to EDIT (only the fields you send change).
Fields: name, title, company, email, phone, imagePath,
link, linkedIn, biography, websiteBiography,
websiteOverride, tags, unListed.
Returns {"status", "speakerId", "created"}.
POST /deleteSpeaker body: {"speakerId"}
Visibility: new speakers default to unListed:true (Invited, not shown on the public
widgets). Send "unListed":false to publish; publishing auto-confirms an unconfirmed
speaker, and unlisting a confirmed speaker keeps it confirmed.
Sessions (permission: sessions):
GET /getSessions -> array of sessions
POST /upsertSession body: omit "sessionId" to CREATE (name required); include
"sessionId" to EDIT. Fields: name, date, timeStart,
timeEnd, location, format, difficulty, synopsis, tags,
capacity, track, tintColor, handOutLink,
additionalContentLabel, additionalContentLink,
ticketRedemption (+Label/+Description), hasPreRegistration,
hasLiveQA, managedQA, hasPoll, hasSponsorship,
sponsorshipLink, sponsorImagePath, unListed, contentData,
websiteOverride, websiteContentData. Speakers are added via
speaker content sections (below), not a separate field.
Returns {"status", "sessionId", "created"}.
POST /deleteSession body: {"sessionId"}
Sponsors (permission: sponsors):
GET /getSponsors -> array of sponsors
POST /upsertSponsor body: omit "sponsorId" to CREATE (name required); include
"sponsorId" to EDIT. Fields: name, tier, link, hasPage,
hasBanner, imagePathLogo, imagePathBanner, biography,
downloadLink1, downloadLabel1, downloadLink2, downloadLabel2,
representativeEmails, unListed, contentData.
Returns {"status", "sponsorId", "created"}.
POST /deleteSponsor body: {"sponsorId"}
All delete endpoints soft-delete (recoverable in the console).
Visibility, all object types: "unListed":true hides a record from the public website and
app widgets while leaving it visible in the console. New sessions and sponsors default
to unListed:false (published); new speakers default to unListed:true (see above).
FIELD TYPES (bodies are type-checked; a wrong type is rejected with 400, nothing is saved)
Not every field is a string. Check these before you send:
track (session) INT - the position of the track in the event's track
list, from 0. The stage or room NAME goes in "location".
tier (sponsor) INT - the position in the event's sponsor-tier list, from 0.
tintColor (session) INT - 32-bit ARGB (4294967295 = white). A hex string
like "#3366FF" is accepted and converted.
capacity (session) INT - 0 means unlimited.
tags (session, speaker) STRING, comma-separated (an array is accepted too).
representativeEmails (sponsor) STRING, comma-separated (an array is accepted too).
ticketRedemption (session) STRING - the ticket tier redeemable at the session,
not an on/off flag. Empty means none.
The boolean fields are exactly: hasLiveQA, hasPoll, hasPreRegistration, hasSponsorship,
managedQA, unListed, websiteOverride, hasPage, hasBanner. Every other field is a string,
an integer or an array as listed above.
Formats: date "YYYY-MM-DD", timeStart/timeEnd 24-hour "HH:MM", emails are lowercased.
Accepted loosely: "150" for an int, "true"/"yes"/1 for a boolean.
Omitted = unchanged on an edit. To clear a field send "" / 0 / false, never null.
A 200 may include "warnings" (saved, but check it) and "ignoredFields" (keys that are
not writable there and were dropped) - read them, they tell you what went unwritten.
CONTENT SECTIONS (the "contentData" on sessions and sponsors)
contentData is an ORDERED ARRAY of {"type","data"} blocks, on both read and write -
what getSessions/getSponsors return can be posted straight back. Types:
title -> {"content": "heading text"}
paragraph -> {"content": "<rich text string, same format as biography below>"}
image -> {"content": "https://image-url"}
button -> {"content": {"buttonText": "...", "buttonUrl": "..."}}
sponsor -> {"content": "<sponsorId>"}
speaker -> {"speakerType": "Label", "speakerIds": ["<speakerId>", ...]}
Sponsor/speaker references must exist in this event and not be hidden or deleted, or the
write is rejected with 400. For speaker sections send only speakerIds; the API fills in
the names and returns both speakerIds and speakerList on read. To add speakers to a
session, use speaker sections - there is no separate speakers field.
RICH TEXT FORMAT (biography, and paragraph content sections)
Rich text is a JSON STRING containing an array of Delta ops
(Fleather/Parchment, Quill-compatible). Each op is {"insert": "text"} with an
optional "attributes" object. Attribute keys:
inline: b (bold), i (italic), u (underline), s (strike), a (link URL)
block (put on the line's trailing "\n"): heading (1-6), block ("ul" or "ol"
for list items), alignment ("left"/"right"/"center"/"justify")
Heading meanings: 1-3 are headings, 4 is body-text size, 5 is grey sub-text,
6 is a red warning line.
Example biography value (as a single JSON string):
[{"insert":"About Jane"},{"insert":"\n","attributes":{"heading":2}},
{"insert":"Keynote speaker and researcher.\n"}]
Plain text is also accepted, but renders without formatting.
EXAMPLE REQUEST (add a guest)
curl -X POST "$EVENTVAULT_API_BASE_URL/addGuest" \
-H "x-api-key: $EVENTVAULT_API_KEY" \
-H "x-client-id: $EVENTVAULT_CLIENT_ID" \
-H "x-event-id: $EVENTVAULT_EVENT_ID" \
-H "x-timestamp: $(date +%s%3N)" \
-H "Content-Type: application/json" \
-d '{"userEmail":"[email protected]","name":"Jane Doe"}'
TO START
Load the credentials, then call one GET endpoint your permissions allow (e.g.
GET /getSpeakers, /getSessions, /getSponsors, or /getGuestCount) to confirm you can
reach the API. A 403 just means the key lacks that scope - try another. Tell me it
worked (or what failed), and then wait for my first instruction.
Once the assistant confirms it can reach the API, just tell it what you want done. It will make the calls for you and report back. For the full reference, see Guests, Tickets, Speakers, Sessions, and Sponsors; for the formats, see Rich Text Format and Content Sections.