Offentlig API & API-nøkler
Programmatisk tilgang til arbeidsområdet — les prosjekter, økter, egendefinerte hendelser og segmenter, og knytt kunde-ID-er til økter — sikret med API-nøkler avgrenset til arbeidsområdet.
1. Oversikt
Med MousePlayer-API-et kan du hente data fra arbeidsområdet til egne dashbord, datavarehus eller interne verktøy. Bortsett fra å knytte kunde-ID-er til økter (identify, krever en nøkkel med skrivetilgang, se Nøkkelomfang) er det skrivebeskyttet: ingen data kan endres eller slettes via API-et.
- Basis-URL:
https://www.mouseplayer.com/api/v1/ - Alle svar er JSON.
- Hver forespørsel autentiseres med en API-nøkkel og avgrenses automatisk til arbeidsområdet nøkkelen tilhører — en nøkkel fra ett arbeidsområde kan aldri se data fra et annet, heller ikke ved et uhell.
- Hele øktavspillingsopptaket (musebevegelser, DOM-øyeblikkskopier) er ikke tilgjengelig via API-et. Du får øktmetadata, sidevisninger, egendefinerte hendelser og segmenter — nok til å bygge rapporter og dashbord uten å flytte rundt på rå avspillingsdata.
2. Autentisering
Opprett og administrer API-nøklene under API-nøkler i kontomenyen (/api-keys). Bare arbeidsområdets eiere og administratorer kan opprette eller tilbakekalle nøkler.
Hold nøkkelen hemmelig. Den gir lesetilgang til alt i arbeidsområdet. Hele nøkkelen vises nøyaktig én gang, rett etter opprettelse — lagre den i en passordbehandler eller et hemmelighetshvelv. Mister du den, tilbakekaller du den og oppretter en ny.
Send nøkkelen som et Bearer-token i Authorization-headeren i hver forespørsel:
Manglende, feilformede eller tilbakekalte nøkler gir svaret 401:
Abonnementskrav
REST-API-et inngår i abonnementene Business og Enterprise. Abonnementet hentes fra arbeidsområdets eier, slik at inviterte teammedlemmer arver det. Kontrollen kjøres ved hver forespørsel, ikke bare når en nøkkel opprettes — nedgraderes et arbeidsområde, slutter eksisterende nøkler å virke og returnerer 403.
Nøkkelomfang
Hver nøkkel viser omfanget i sitt eget prefiks, så du kan se hva en nøkkel gjør bare ved å se på den — i en .env, i en sak, i en terminal.
| Prefiks | Betydning |
|---|---|
mp_ro_ | Bare lesing. Leser prosjekter, økter, hendelser og segmenter. Kan ikke endre noe. |
mp_rw_ | Lesing og skriving. Alt ovenfor, pluss å knytte til kunde-ID-er via identifikasjonsendepunktet. |
403 med en melding som sier hva nøkkelen tillater og hva endepunktet trenger. Omfanget kan ikke endres etterpå — opprett en ny nøkkel og tilbakekall den gamle.3. Frekvensgrenser
Hver API-nøkkel er begrenset til 60 forespørsler per minutt, målt i et rullerende tidsvindu. Overskrider du det, får forespørslene svaret 429 til tidsvinduet er tømt:
Bygger du noe som trenger en høyere grense? Kontakt Support og fortell om bruksområdet.
4. Endepunkter
GET/api/v1/projects
Lister alle prosjekter (sporede nettsteder) i arbeidsområdet.
GET/api/v1/projects/{channelid}/sessions
Lister besøksøkter tatt opp for et prosjekt, nyeste først. Sideinndelt.
| Spørringsparameter | Beskrivelse |
|---|---|
page | Sidenummer, som standard 1. |
per_page | Resultater per side, som standard 25, høyst 100. |
since | Bare økter som startet på eller etter denne datoen (YYYY-MM-DD). |
until | Bare økter som startet på eller før denne datoen. |
GET/api/v1/sessions/{session_id}
Metadata for én økt og dens sidevisninger. Hele avspillingsnyttelasten er bevisst utelatt — bruk avspilleren i dashbordet til det.
GET/api/v1/sessions/{session_id}/events
Egendefinerte hendelser utløst under en økt (de samme hendelsene du sender med mp('event', ...)), inkludert parameterne.
GET/api/v1/projects/{channelid}/segments
Lister besøkssegmentene definert for et prosjekt (både prosjektspesifikke segmenter og segmenter for hele arbeidsområdet).
5. Knytt til en kunde-ID fra baksystemet
Nettleseren vet ofte ikke hvem som sitter der. I et B2B-produkt avklares identiteten etter innlogging — i baksystemet ditt. I en butikk avklares den med ordrebekreftelsen. Dette endepunktet er for akkurat det øyeblikket.
POST /api/v1/sessions/{session_id}/identify
Authorization: Bearer mp_live_xxxxxxxxxxxx
Content-Type: application/json
{"user_id": "customer-4711"}
// 200 OK
{"data": {"session_id": "s_a1b2c3", "user_id": "customer-4711",
"changed": true, "previous": null, "webhook_queued": true}}ID-en vises deretter i øktlisten og kan søkes opp der, og webhooken session_identified utløses — slik når den CRM-et ditt.
"changed": false og ingen webhook sendes. En gjentatt ordre oppretter ikke et nytt lead.| Status | Når |
|---|---|
400 | Manglende felt, user_id over 128 tegn, eller kontrolltegn i det. Vi avviser i stedet for å avkorte — en ID forkortet uten varsel samsvarer ikke med noe i CRM-et og ser likevel ut som suksess. |
404 | Økten finnes ikke eller tilhører ikke arbeidsområdet ditt. Bevisst samme svar i begge tilfeller. |
403 | Arbeidsområdets abonnement omfatter ikke API-et. |
6. Webhooks: kontroller signaturen
Webhooks konfigureres per prosjekt under Integrasjoner, der du også finner signeringshemmeligheten. Hver levering har disse headerne:
| Header | Betydning |
|---|---|
X-MousePlayer-Event | Hendelsesnavn, f.eks. session_identified |
X-MousePlayer-Timestamp | Unix-sekunder — inngår i den signerte teksten |
X-MousePlayer-Attempt | 1 ved første forsøk, høyere ved nye forsøk |
X-MousePlayer-Signature | sha256=<hex> |
Signaturen er en HMAC-SHA256 over timestamp + "." + raw body, med prosjektets signeringshemmelighet som nøkkel.
// PHP $erwartet = 'sha256=' . hash_hmac('sha256', $timestamp . '.' . $rawBody, $secret); if (!hash_equals($erwartet, $signature)) { http_response_code(401); exit; } // Node const expected = 'sha256=' + crypto.createHmac('sha256', secret) .update(timestamp + '.' + rawBody).digest('hex');
Levering og nye forsøk
En mislykket levering forsøkes på nytt etter 1 min, 5 min, 15 min, 1 t og 6 t, deretter gis den opp. 4xx-svar bortsett fra 408 og 429 forsøkes ikke på nytt — de sier "ikke slik", ikke "ikke akkurat nå". Svar 2xx raskt og gjør arbeidet etterpå; leveringen får tidsavbrudd etter 10 sekunder.
Tilgjengelige hendelser
| Hendelse | Utløses |
|---|---|
session_identified | Når en økt først får en kunde-ID — fra nettleseren eller API-et |
session_ended | Én gang, når økten avsluttes |
goal_reached | Én gang per økt, når en egendefinert hendelse oppfyller et av målene dine. Bare mål av typen «event» — mål for URL, varighet, sidevisning og trakt evalueres ikke. Inneholder goal_id, goal_name, goal_value og currency. |
high_value_session | Når en besøkende første gang passerer prosjektets verditerskel på en bestemt dag. Terskelen er avledet fra din egen poengfordeling (90-persentilen fra de siste 90 dagene), ikke et fast tall, og finnes ikke før minst 20 besøkende er poengsatt. Inneholder visitor_id, value_score, threshold og dagens økt som er mest verdt å se. |
funnel_dropoff | Ved slutten av en økt som gikk inn i en av traktene, men ikke fullførte den. Angir trinnet den stoppet ved (dropped_at). Frafall er fravær av en hendelse og kan derfor først fastslås når økten er over. Økter som aldri gikk inn i trakten, er ikke frafall og utløser ikke hendelsen. |
high_friction_session | Én gang per økt, når friksjonspoengene først når terskelen (som standard 60 av 100). Inneholder friction_score, signalene bak den (reasons) og signalet som krysset grensen (trigger). |
element_broken | Én gang, når et sporet element ikke har funnet noe i noen kontrollerte sidevisninger på flere dager — vanligvis etter en relansering. Den utløses på nytt først etter at markeringen har funnet treff og så sluttet å virke igjen. Denne hendelsen tilhører ingen økt: session_id og session_url er null, link_url åpner i stedet markeringen, og subject_id angir markeringen — likt for alle versjoner, så en ny selektor som igjen slutter å virke, kobles til den åpne hendelsen. Inneholder rule_id, rule_name, selector, page, checked_page_views, window_days og last_matched. Ingen besøksdata. |
element_recovered | Klarsignalet for element_broken: når markeringen faktisk finner et element igjen — for få sidevisninger er ikke nok. Sendes bare hvis element_broken ble sendt via webhook, og har ingen egen bryter: et abonnement på element_broken inkluderer den. Samme subject_id, slik at PagerDuty løser hendelsen og Opsgenie lukker varselet. Inneholder matched_page_views og checked_page_views i tillegg. |
anomaly_detected | Én gang daglig, når gårsdagen tydelig skilte seg fra de 28 foregående dagene: langt færre eller flere økter, lavere målrate, flere økter med friksjon eller JS-feil. Samme måling og retning forblir stille i en uke (kan justeres). Denne hendelsen tilhører ingen økt: session_id og session_url er null, link_url åpner prosjektoversikten, og subject_id angir måling, retning og dag. Inneholder metric (sessions, goal_rate, friction_rate, js_error_rate, lcp_p75, inp_p75, cls_p75), direction, day, value, expected, sessions, robust_z, z_score og en lesbar summary og hint. Ingen besøksdata. For Web Vitals erstatter measurements verdien sessions, og page (tom for hele nettstedet) og device (desktop eller mobil) sier hvor det skjedde; link_url åpner da Web Vitals-fanen. |
rage_click | Ved oppdaget raseriklikk |
error_detected | Ved et unntak i grensesnittet |
ce | Samlet abonnement på egne egendefinerte hendelser. Det omfatter ikke hendelsene ovenfor — de har egne brytere. |
7. Feil & statuskoder
| Status | Betydning |
|---|---|
200 | Vellykket. |
401 | Manglende, feilformet eller tilbakekalt API-nøkkel. |
404 | Det forespurte prosjektet eller den forespurte økten finnes ikke, eller tilhører ikke arbeidsområdet ditt. |
429 | Frekvensgrensen er overskredet — du sender over 60 forespørsler/minutt med denne nøkkelen. |
403 | Arbeidsområdets abonnement omfatter ikke REST-API-et. Meldingen angir både nødvendig og gjeldende abonnement. |
8. Sikkerhetsmerknader
- Lesenøkler (mp_ro_) kan ikke endre noe. Skrivenøkler (mp_rw_) kan bare knytte til kunde-ID-er; ingen nøkkel kan slette data eller eksportere rå avspillingsdata.
- Hver forespørsel avgrenses automatisk til nøkkelens eget arbeidsområde — det er ikke mulig å sende en annen arbeidsområde-ID og se andres data.
- Tilbakekall en nøkkel når som helst fra /api-keys; tilbakekallingen gjelder umiddelbart.
- Behandle API-nøkkelen som et passord. Hvis du ved et uhell committer en i et offentlig kodelager, tilbakekall den straks og opprett en ny.
Avgrensede hendelsessider (API v1, 14. oktober 2026)
GET /api/v1/sessions/{session_id}/events returnerer som standard opptil 100 hendelser. Sett per_page til et heltall fra 1 til 100. Følg pagination.next_cursor ved å sende cursor uendret i neste forespørsel; behold samme økt og arbeidsområde. Hendelser sorteres etter created_at og event_id. Markører er signert og bundet til økten og arbeidsområdet. Verken totalt antall eller numerisk side returneres.
Eksisterende data-array og params-kart er fortsatt tilgjengelige. pagination.returned er faktisk returnert antall; pagination.has_more angir en ny side. next_cursor er null når alt er hentet. Et svar begrenses til 524288 byte, så en side kan inneholde færre hendelser enn per_page. Per hendelse returneres høyst 128 parameterrader; params_truncated er true hvis flere finnes. Enkeltstående tekstparametere har fortsatt databasegrensen på 255 tegn. Avkortede parametere er ikke tilgjengelige via dette endepunktet. Å redusere per_page øker ikke parametergrensen.
Ugyldige sidestørrelser, endrede markører og markører for en annen økt eller et annet arbeidsområde gir 400. For store data for én hendelse gir 413. Eksisterende tilgangskontroller gir fortsatt 401, 403, 404 eller 409 etter behov.
Grensen er fortsatt 60 autentiserte forespørsler per API-nøkkel per minutt. Når den er brukt opp, returneres 429 med Retry-After: 60. Er Redis eller begrenseren utilgjengelig, får forespørsler 503 med Retry-After: 5; de slippes aldri gjennom uten grense. Respekter Retry-After og legg til tilfeldig ventetid; ikke prøv igjen i en tett løkke. Feil i hendelsesdatabasen gir også 503. Markører fryser ikke en øyeblikkskopi: samtidige innsettinger med eldre tidsstempler kan kreve en ny gjennomgang.
GET /api/v1/sessions/s_example/events?per_page=25 GET /api/v1/sessions/s_example/events?per_page=25&cursor=SIGNED_CURSOR
/api/v1/native er en kontrollrute i baksystemet bare for Dev, for forhåndsvisningen av det native SDK-et. Den forblir deaktivert i produksjon. Bearer-nøkler for baksystemet trenger leseomfang for list/replay og skriveomfang for register/grant/delete/disable. Ytterligere tilgjengelighetskontroller gjelder for native-forhåndsvisning. Bygg aldri permanente API-nøkler for arbeidsområdet inn i en mobilapp.