Brukerhistorier API-katalog (alle detaljer)

Brukerhistorier API-katalog (alle detaljer) ()


API-katalogen
Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser
BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er.
1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte
Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.
BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog
BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet
BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt.
29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder.
30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er.
12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI.
BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes
BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.
BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.
Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk
31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet.
28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.).
14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.
Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.
9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy
34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser.
Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>
Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>
Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder.
Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API
BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon]
Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.
35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert.
23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte]
Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne
25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data
Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design
BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning.
EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester
BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester
Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene.
Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet
7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet.
5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg]
Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes
BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett
Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester
BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen.
BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.
Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid
26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig.
BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby.
Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres
Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter.
Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.
BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige.
BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer
BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles.
20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.
BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem]
BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold.
BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre.
21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene]
BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres
Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres
Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser
10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser.
Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et
BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?]
BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres.
32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen]
17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene.
Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer
Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid
BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer
Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester
BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse]
BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter
Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig
Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne
Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet
BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.
Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen
BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.
BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data]
BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv.
Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem
19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede]
Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester
Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester
Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling
Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring.
Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.
Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett
BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API
BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere.
Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles
Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester
Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste
Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.
Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).
Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer)
BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler]
Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte.
Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast
BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp


		API-katalogen	Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett
		API-katalogen	Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer
		API-katalogen	Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et
		API-katalogen	Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser
		API-katalogen	Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast
		API-katalogen	Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API
		API-katalogen	Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.
		API-katalogen	Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres
		API-katalogen	Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid
		API-katalogen	Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester
		API-katalogen	Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes
		API-katalogen	Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet
		API-katalogen	EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester
		API-katalogen	Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design
		API-katalogen	Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne
		API-katalogen	Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API
		API-katalogen	Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.
		API-katalogen	Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk
		API-katalogen	Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes
		API-katalogen	Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.
		API-katalogen	Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser
		API-katalogen	Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet
		API-katalogen	Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen
		API-katalogen	Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling
		API-katalogen	Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem
		API-katalogen	Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles
		Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser	1.Som API-forvalter ønsker jeg at katalogen dekker informasjonsbehovet til de som skal benytte API-ene jeg forvalter, slik at jeg slipper å besvare henvendelser fra dem/redusere antall henvendelser [frigjøre ressurser]
		Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser	15. Som API-forvalter/eier ønsker jeg en ensartet og samlet beskrivelse av alle våre API-er slik at det er enkelt for brukerne å gjenbruke sin kunnskap om de skal bruke flere API-er.
		Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser	BTI004 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å redusere mine forvaltningskostnader, for eksempel for å få redusert manuelle henvendelser
		Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser	BTI005 Som API-tilbyder ønsker jeg å tilby informasjon om mine API’er i henhold til en standard for å sikre at det blir enkelt å ta API’ene i bruk slik at vi bidrar til forenkling og samordning
		Som API-forvalter ønsker jeg at mine API-beskrivelser følger et standard med veiledning og verktøystøtte slik at det er enkelt for brukerne og jeg kan redusere mine forvaltningskostnader og henvendelser	Det er behov for enkel tilgang til data av god kvalitet, og som er beskrevet på en standardisert måte
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	BAM02 - Som ansvarlig for API-management ønsker jeg å dokumentere mitt API slik at utviklere raskt kan benytte API-et for tilgang til de data API-et representerer
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	12. Som APi-forvalter/eier ønsker jeg at standarder og beskrivelser er helt maskinlesbare slik at høsting og bruk kan automatiseres og min rolle automatiseres bort eller erstattes av AI.
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	30. Som API-portaleier ønsker jeg at alle skal tilby sin informasjon på samme format, OG at alle har et eget API som beskriver sin katalog eller sitt API, slik at portalen enklest mulig kan høste og sammenstille informasjon om API-er.
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	29. Som API-katalogeier med en eksisterende API-dokumentasjon ønsker jeg å bruke eksisterende API-dokumentasjon slik at jeg slipper å vedlikeholde API-dokumentasjon (manuelt) flere steder.
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	22. Som en API-forvalter med allerede eksisterende API-katalog, ønsker jeg at løsningen er fleksibel(?)/legger til rette for automatisk høsting, slik at jeg kan vedlikeholde dokumentasjonen min lokalt.
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	BAM04 - Som leverandør av API-management-verktøy ønsker jeg at jeg å kunne tilby automatisk integrasjon med den felles API-katalogen slik at jeg kan selge mer av produktet mitt ved å vise til at det støtter opp under de nasjonale føringene.
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	BAM01 - Som ansvarlig for API-management ønsker jeg å publisere mine API i en API-katalog slik at utviklere raskt kan finne frem til mitt API/økt synlighet
		Som API-forvalter ønsker jeg at API-beskrivelsene skal være maskinlesbare og publisert/høstet av felles API-katalog gjennom et API eller tilsvarende slik at jeg kan vedlikeholde dokumentasjonen lokalt og ett sted.	BAM07 - Som leverandør av API-management-verktøy ønsker jeg å kunne publisere dokumentasjon om API fra mitt API management verktøy til en felles offentlig API katalog
		Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes	BA25. Som API-konsument ønsker jeg at beskrivelser av API-er som ikke lengre er tilgjengelige, skal fjernes fra API-katalogen, slik at jeg slipper å lese om API-er som jeg uansett ikke kan bruke.
		Som API-konsument ønsker jeg at API-beskrivelser er oppdaterte, og at API-er som ikke lenger er tilgjengelig/deprecated fjernes fra katalogen slik at jeg ikke studerer beskrivelser som ikke kan brukes	BA36. Som API-konsument ønsker jeg at noen tar jobben med å holde oversikt over om API-er er tilgjengelige, utilgjengelige, stabilt, deprecated etc slik at jeg slipper å begynne å ta det i bruk først før jeg oppdager det.
		Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk	14. Som API-forvalter/eier ønsker jeg en ensartet og samlet API-katalog slik at det blir enklere å publisere informasjonen.
		Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk	28. Som API-katalogeier ønsker jeg å, slik at jeg kan ha en total oversikt over API-ene våre kunne vite hvilke API-er min virksomhet tilbyr (og forvalte de på felles måte, vite hvem som bruker hvilke API-er osv.).
		Som API-forvalter ønsker jeg en å samle beskrivelser av API-ene våre og andres slik at det er enkelt å få oversikt over API-er og bruk	31. Som API-portaleier ønsker jeg å få inn statistikk fra API-forvaltere slik at vi kan få et overordnet oversikt for hele sektoren/landet.
		Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.	Som API-eier ønsker jeg å kunne beskrive funksjonaliteten i API-et på en overordnet måte slik at brukere får et innblikk i hva API-et innholder.
		Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.	Som utvikler i Altinn ønsker jeg å kunne registrere tredjepart API uten at API-eier har kjennskap til dette slik <hensikt>
		Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.	Som utvikler i Altinn ønsker jeg å kunne registrere de API jeg utvikler for mine T.3 applikasjoner slik at <hensikt>
		Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.	34. Som API-katalogeier som ikke har en katalog, så ønsker jeg enkel måte å eksponere API-er på, ikke egen katalog med maskinlesbar beskrivelse, slik at jeg slipper å lage et eget verktøy med egne beskrivelser.
		Som API-forvalter ønsker jeg en godt dokumentert felles løsning for registering av API-beskrivelser slik at jeg slipper å installere egne verktøy.	9. Som API-forvalter ønsker jeg en felles løsning for API-dokumentasjon som er så god at jeg selv ønsker å bruke løsningen fremfor andre verktøy
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	23. Som API-forvalter ønsker jeg at de API-ene jeg tilbyr skal være lette å finne og ta i bruk for de som har verdi av dem, slik at innsatsen jeg har lagt ned i API-ene får størst mulig verdi [forsvare kostnadene ved utviklingen/forvaltningen av API-ene/generere størst mulig nytte]
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	24. Som API-forvalter (f.eks. av hotell.difi.no) ønsker jeg at API-ene er lette å finne og ta i bruk slik at verdien blir realisert.
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	BFDK02 - Som forretningsutvikler ønsker jeg å søke etter API, slik at jeg raskt kan finne ut om det finnes data jeg kan gjenbruke
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	35. Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	BA1. Som API-konsument (student) ønsker jeg å filtrere på dataformater i oversikter over (åpne) API-er slik at jeg kan finne API-er i det formatet jeg ønsker å lære mer om eller filtrere ut de jeg ikke kan noe om.
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	Som API-katalogeier ønsker jeg å kategorisere API-innslagene, slik at det kan differensieres mellom de.
		Som API-konsument ønsker jeg å søke og filtrere langs ulike kategorier (f.eks. formater, tilgangsnivå) på API slik at jeg minimerer tiden jeg bruker på å finne rett API	BB8. Som API-konsument ønsker jeg at utforskingsfasen/exploration/discovery gir meg rask oversikt og innsikt slik at jeg minimerer tiden jeg bruker på å velge et utsnitt eller må bruke egne verktøy for å skaffe meg oversikt. [dokumentasjon]
		Som API-konsument ønsker jeg at API-er av autoritativ art priorites slik at de er lette å finne	25. Som API-forvalter som forvalter API-er til autoritative data ønsker jeg at API-katalogen skal prioritere presentasjon av mine API-er fremfor API-er som tilbyr samme data, men fra ikke-autoritative kilder, slik at API-brukerne ikke ubevisst bruker ikke-autoritative data
		Som API-konsument ønsker jeg å se request og respons på et API slik at jeg kan planlegge design	BFDK06 - Som arkitekt ønsker jeg å se hvilke data jeg må benytte for å gjøre oppslag mot et API og hvilke data jeg får tilbake slik at jeg kan planlegge design av løsning.
		EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester	BFDK03 - Som forretningsutvikler ønsker jeg å se detaljerte beskrivelser av APIene, slik at jeg kan vurdere om de er av tilstrekkelig kvalitet for bruk i mine tjenester
		EPOS 4: Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester	Datakonsumenter har behov for et ryddig avtaleregime for tilgang til dataene.
		Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet	5. Som API-forvalter ønsker jeg at API-katalogen kan vise min Swagger-dokumentasjon slik at jeg bare kan eksponere for eksempel Swagger-data (YAML) og slipper å drifte min egen Swagger UI-nettside. [relatert til Swagger-brukerhistorien, trur eg]
		Som API-forvalter ønsker jeg at API-katalog kan plukke opp min swagger dokumentasjon slik at jeg kan benytte dette verktøyet	7. Som API-forvalter har jeg behov for å selv velge hvor selve dokumentasjonen skal ligge, slik at jeg kan bruke de verktøyene som er mest hensiktsmessig til formålet.
		Som dataeier ønsker jeg å knytte API til datasettet slik at jeg kan vise hvilke distribusjoner som finnes	BFDK07 - Som datasetteier (og som beskriver datasett i datakatalogen) ønsker jeg å kunne kople beskrivelser av APIer (i flertall) til et gitt datasett, slik at jeg kan vise hvilke distribusjoner som finnes av et datasett
		Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester	BFDK01 - Som forretningsutvikler ønsker jeg å se hvilke datasett som tilbyr API, slik at jeg kan vurdere om det kan brukes i mine tjenester.
		Som forretningsutvikler ønsker jeg å se filtrere på datasett som tilbyr API slik at jeg kan benytte det i mine tjenester	BFDK04 - Som forretningsutvikler ønsker jeg å filtrere på datasett som har API, slik at jeg bedre treff på mine søk i katalogen.
		Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid	BFDK08 - Som datasetteier (som beskriver datasett i datakatalogen) ønsker jeg å kunne plukke fra API-beskrivelsen dataelementene som jeg ønsker å ta med i datasettbeskrivelsen, slik at dataelementene jeg tar med gjenspeiler det som APIet virkelig kan tilby.
		Som dataeier ønsker jeg at relevante opplysninger fra API-beskrivelsen er tilgjengelig i datasettbeskrivelsen slik at jeg unngår dobbeltarbeid	26. Som API-forvalter ønsker jeg at opplysninger som er relevante for datakatalogen og som finnes i API-et (feks “sist oppdatert”), høstes til datakatalogen slik at datasettbeskrivelsen er så god som mulig.
		Som API-eier ønsker jeg å publisere API-er som ikke kan knyttes til et datasett slik at også mine mine API-er som gjør beregninger e.l. kan publiseres	Som API-eier ønsker jeg å kunne beskrive et API som ikke nødvendigvis kan knyttes til et datasett, slik at også dynamiske tjenester kan synliggjøres for andre konsumenter.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BB19. Som API-konsument ønsker jeg å diskutere semantiske og tekniske spørsmål i en åpen kanal (wiki, github issues el liknende) for APIet jeg bruker, slik at brukerne kan hjelpe hverandre og tilbyder kan kommunisere åpent med sitt økosystem. [nettverk, dokumentasjon]
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BA22. Som API-konsument (app-utvikler) ønsker jeg en landingsside hvor jeg kan stille spørsmål om bruk av API-et slik at jeg kan bruke det mest mulig hensiktsmessig, og gjerne med henvisninger til kjent brukt av API-et.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	21. Som API-forvalter ønsker jeg å få en effektiv kanal for å få tilbakemeldinger og behov fra de som bruker API-ene mine, slik at det blir lettere å prioritere riktig ved videreutvikling av API-ene [styrke dialog med brukerne av API-ene]
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BA6. Som API-konsument ønsker jeg å kunne på en enkel måte gi kontekstavhengige tilbakemeldinger til API-forvalteren, slik at dokumentasjonen og eller API-et blir bedre.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BA52. Som API-konsument ønsker jeg en enkel måte å rapportere inn feil i datakatalog (f.eks. Lenker som ikke fungerer) slik at jeg slipper å bla i utdatert innhold.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BB11. Som API-konsument (analytiker) ønsker jeg mulighet for å legg inn spørsmål, tips, eksempler knyttet til APIer slik at jeg kan øke min egen, andre brukere og api-forvalternes kjennskap om semantikk, selve APIen og bruk [økosystem]
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	20. Som API-forvalter ønsker jeg at brukerne av mitt API skal ha en åpen kommunikasjon med meg og hverandre om hvilke behov de har som ikke er dekket i dag, slik at min videreutvikling treffer flest mulig brukere på en tilstrekkelig måte.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BA50. Som API-konsument, ønsker jeg å kunne gi tilbakemeldinger til god (eller dårlig) “beste praksis” for API-er, slik at dette kan være til hjelp for framtidige API-er som utvikles.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BA51. Som API-konsument ønsker jeg mulighet til å gi tilbakemeldinger slik at jeg kan melde fra om feil eller foreslå forbedringer
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	BAM13 - Som ansvarlig for API-management ønsker jeg at brukerne av mine API-er skal kunne gi innspill til endringer av mine API-er, slik at jeg gjøre API-ene mine mer brukervennlige.
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	Som API-forvalter ønsker jeg å kunne motta strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for mine tjenester slik at tjenestene kan forbedres
		Som API-konsument ønsker jeg å kunne gi komme i dialog med API-eier og andre API-konsumenter og gi tilbakemeldinger, tips, stille spørsmål, melde om feil, gi innspill til endringer slik at dette kan hver til hjelp for meg, andre og data-eier.	Som API-konsument ønsker jeg å kunne gi strukturerte tilbakemeldinger (f.eks. feil) og endringsforslag for tjenester slik at tjenestene kan forbedres
		Som API-konsument ønsker jeg kunnskapsbase (f.eks. FAQ funksjonalitet) slik at jeg som bruker kan få svar på kjente utfordringer og ikke behøver å bruke tid på henvendelser	10. Som en API-forvalter ønsker jeg å kunne ha “FAQ-funksjonalitet” (eller kunnskapsbase), slik at brukerne mine lettere kan få tak i svar på kjente utfordringer og jeg kan redusere kostnader ved å håndtere brukerhenvendelser.
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	17. Som API-forvalter ønsker jeg å vise frem eksempel på bruk av mine API-er slik at verdien av API-ene blir synliggjort og det kan inspirere flere til å bruke API-ene og hvordan bruke API-ene.
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	32. Som API-bruker ønsker jeg å registrere en anvendelse slik at jeg kan oppgi den i API-kallet. Alternativt: Som API-forvalter ønsker jeg at brukere kan registrere seg med en ID som de bruker i API-kallet slik at jeg kan koble trafikk og anvendelse. [f.eks. ved overbruk av API-et kan man lett kontakte den som har satt opp anvendelsen]
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	18. Som API-forvalter ønsker jeg oversikt over integrasjoner mot mine API-er slik at konsekvenser og kostnader ved endringer kan forutses og minimeres.
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	BA14. Som API-konsument ønsker jeg lenker til applikasjoner som bruker datasettet, slik at jeg kan finne gode eksempler på bruk av API-et og datasettet. [kommentar: også programvarebibliotek og anna kodeverk som er relevant
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	BAM08 - Som ansvarlig for API-management ønsker jeg oversikt over brukerne av mitt API slik at jeg kan formidle endringer i APIet. [Livar: duplikat av BAM03?]
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	16. Som API-forvalter ønsker jeg å vite av hvem og hvor ofte mine API-er brukes (trafikkdata og bruksmønstre), slik at jeg optimere tilgang til API-er og ta stilling til hvilke API-er som eventuelt skal avvikles, samt kunne få grunnlag for å kunne rapportere på gevinstrealisering.
		Som API-forvalter ønsker jeg å kjenne til brukere av API slik at jeg kan formidle endringer i API-et	BB20. Som API-konsument ønsker jeg eksempel på bruk av dataene som en del av dokumentasjonen av API-et, slik at de er enklere å fortså og ta i bruk [dokumentasjon]
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	BAM03 - Som ansvarlig for API-management ønsker jeg å notifisere endringer i mine API til dem som benytter API-ene slik at man ikke bryter kontrakter
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	BA42. Som API-konsument ønsker jeg varsler om “breaking changes” slik at jeg kan gjøre de nødvendige endringene før de brekker mine systemer/applikasjoner også. [f.eks. ved registrere e-postadresse]
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	BA43. Som API-konsument ønsker jeg å bli varslet om at et API er “deprecated” (skal tas ut av bruk), slik at jeg kan oppdatere min applikasjon.
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	Som API-forvalter ønsker jeg en enkel måte å varsle endringer spesifikasjon av tjenester
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	BFDK11 - Som konsument ønsker jeg å abonnere på varslinger om etablering, endring, driftsstans og avvikling av API’er slik at jeg kan tilpasse meg endringer
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	Som ansvarlig for API-Management ønsker jeg en enkel måte å varsle endringer i oppetid
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	Som API-forvalter/ansvarlig for API-management ønsker jeg en enkel måte å kommunisere livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg kan avvikle tjenester når det er ønskelig
		Som API-konsument ønsker jeg å bli varslet om endringer i API slik at jeg kan tilpasse meg endringer	Som potensiell API-konsument ønsker jeg å kjenne til livssyklus planer og garantier for en tjeneste (f.eks. nedleggelse/utfasing) slik at jeg ikke gjør meg avhengig av eksterne APIer som kan forsvinne
		Som API-konsument ønsker jeg å kunne sammenlikne API slik at jeg kan vurdere om et API passer bedre enn et annet	BFDK05 - Som forretningsutvikler ønsker jeg å kunne sammenligne APIere, slik at jeg vurdere om et API passer bedre enn et annet for min bruk.
		Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen	BFDK09 - Som datasetteier for historiske (avleverte) data ønsker jeg å kunne koble de historiske datasettene med tilsvarende aktive/nåværende datasett, slik at jeg kan tilby brukerne en helhetlig tilgang til dataene.
		Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen	BB10. Som API-konsument ønsker jeg mulighet til å innhente data om tekstdatasett slik at jeg kan lage analyser av disse og koble til andre kilde. [tekst som data]
		Som API-konsument ønsker jeg at datasett som er relatert til hverandre vises sammen slik at jeg kan få et helhetlig bilde av et fenomen	BA20. Som API-konsument ønsker jeg informasjon om hvor jeg kan finne statiske data som brukes til API-requests (Kommunenr, Kommunenavn..) slik at jeg slipper å lete etter dette selv.
		Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem	19. Som API-forvalter ønsker jeg kontaktinfo til de som bruker mine API slik at jeg kan ta kontakt med de om brukerundersøkelser, driftsmeldinger, endring av API, nye API og liknande. [dersom jeg ikke har egne løsninger for dette allerede]
		Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem	Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere informasjon rettet til enkeltbrukere av tjenester
		Som API-forvalter ønsker jeg kontaktinfo til brukere av mine API slik at jeg kan ta kontakt med dem	Som API-forvalter/API-Management ansvarlig ønsker jeg en enkel måte å kommunisere sensitiv informasjon sikkert til (enkelt)brukere av tjenester
		Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling	Som API-eier ønsker jeg å angi at API’et skal være tilgjengelig i en runtime-tjenestekatalog (SMP/capability lookup) og Altinn tjenestekatalog/Authorization for samtykke og tilgangsstyring.
		Som API-forvalter ønsker jeg å tilgjengeliggjøre API-et i en sanntids-tjenestekatalog (SMP) slik at den kan brukes til capability lookup i sanntids meldingsutveksling	Som API-forvalter ønsker jeg å kunne få overført mine API-definisjoner til en runtime tjenestekatalog (SMP, CapabiliityLookup eller den tekniske endepunktedelen av KoFuVi?) for å kunne legge til metadata for runtime-kall slik at jeg ikke må registrere mine API-definisjoner dobbelt.
		Som API-konsument ønsker jeg at distribusjoner av samme (eller geografisk komplementære) datasett fra ulike tilbydere eller er samlet under et datasett	BTI010 Som API-tilbyder ønsker jeg å kunne se om andre tilbyr det samme eller nesten det samme som meg, så at det er mulig å harmonisere mellom “oss” [Livar: Case der det er fleire API-er som tilbyr det samme? Marit: Brreg og Skatt som har same datasett i FDK. Mathias: Felles studentsystem (FS) i UH-sektoren innheld personinformasjon. Kan ikkje konsoliderast med HR-data. Kan ikkje legge ned ein av dei. Dekker relasjonsfeltet i DCAT behovet?]
		Som bruker ønsker jeg å kunne authentisere meg på en enkel måte mot katalogen slik at jeg kan gi tilbakemeldninger og melde om bruk av et API	BAM17 - Som ansvarlig for API-management ønsker jeg at å tilby effektiv selvregistrering av brukere av API-ene, f.eks. gjennom autentisering via ID-porten/Altinn av dem som tar i bruk API-ene, slik at jeg senker terskelen for å ta API-et i bruk, samtidig som jeg beholder nødvendig oversikt over brukere.
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Som API-konsument ønsker jeg standardiserte autentiserings- og autoriseringsmekanismer som kan gjenbrukes for flere tjenester
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Som API-konsument ønsker jeg single sign on (SSO) mellom flere tjenester jeg benytter slik at jeg unngår separat autentisering mot hver enkelt tjeneste
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Som API-konsument ønsker jeg at nasjonal/delt infrastruktur tilbyr felles mønstre for autentisering og autorisering mot API slik at jeg slipper å bestille og forvalte tilgangsstyring hos hver enkelt tjenestetilbyder.
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Som API-forvalter/API-management ansvarlig ønsker jeg en nasjonal/delt infrastruktur for administrasjon og utstedelse av tilgangstokens for API-konsumenter slik at jeg slipper å utstede og forvalte disse selv (dette gjelder både hjemmelsbasert og samtykkebasert tilgang).
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Som API-forvalter ønsker jeg at definerte APIer i API-katalogen kan overføres til felleskomponenter for tilgangsstyring og autentisering slik at jeg slipper å registrere disse dobbelt (og dermed risikere feil i registreringer)
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	BAM09 - Som ansvarlig for API-management ønsker jeg å kunne administrere nøkler gitt til de enkelte konsumentene slik at jeg enkelt kan fjerne ev. misbruk av API-et
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	BA2. Som API-konsument ønsker jeg umiddelbar tilgang (slipper å vente på manuell tildeling av API-nøkler og tokens) til data (eller testdata) slik at jeg kan vurdere og eventuelt ta i bruk API-et umiddelbart.
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	BA34. Som API-konsument ønsker jeg at eventuelle krav til API-nøkler etc lar seg løse raskt/selvbetjent slik at jeg kan komme i gang raskt. [f.eks. autorisering basert på eksisterende mekanismer fremfor å måtte kontakte forvalter og vente på svar (ID-porten, Altinn), bruksvilkår fremfor avtaler]
		Som API-konsument ønsker jeg å beskrive standardiserte autentiserings- og autorisaksjonsmekansimer som kan gjenbrukes på tjenester beskrevet for API-ene slik at tilgangsstyring mot flere tjenester kan forenkles	Datakonsumenter har behov for tilgang til dataene på en enkel og standardisert måte.
		Som API-konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp om jeg står fast	BFDK12 - Som konsument ønsker jeg kontaktinformasjon til brukerstøtte for API slik at jeg kan få hjelp