Hantera prenumeranter

• 

  Free days access

  Skapad 18 Feb 2026

  Vad är det?  Free days access gör det möjligt för dig att ge intresserade läsare gratis tillgång till innehållet i din app under ett begränsat antal dagar. Detta är idealiskt för potentiella prenumeranter som vill prova din app innan de prenumererar. Du bestämmer själv hur många dagar den kostnadsfria provperioden ska vara. När en användare öppnar appen registreras deras enhet automatiskt. Registreringen startar timern för den kostnadsfria provperioden. Användaren får då tillgång till det valda innehållet under det antal dagar du har angett.   Hur ställer man in det?  För att aktivera gratis provdagar, vänligen kontakta oss så att vi kan aktivera funktionen åt dig. Vänligen ange följande: 1. Antal gratistestdagar: Ange hur många dagar gratistillgången ska gälla. 2. Paketslug: Om du själv skapar paketet i PWS, gör det enligt beskrivningen nedan och ange slug för det paket som ska ges tillgång till.   Hur ställer man in ett paket i PWS? Detta steg kan hoppas över om paketet och tjänsten redan är inställda.  Du måste skapa en tjänst och ett paket för att stödja publiceringstaggarna.     I Workspace går du till Inställningar -> Pakethantering. Klicka på ”Tjänster” -> ”Ny”. Lägg till ett namn på tjänsten och välj den eller de titlar du vill ge åtkomst till.  Skapa sedan ett nytt paket och koppla det till den tjänst du just har skapat.     Klicka på ”Tjänster” -> ”Ny” Lägg till ett namn på tjänsten, ge den en slug och välj den tjänst du just har skapat.  Skicka oss den valda sluggen via e-post. Om du behöver hjälp med att konfigurera detta hjälper vi dig gärna.   Bra att veta  För närvarande kan endast ett paket anslutas till auktoriseraren. Free days authorizer fungerar endast i de inbyggda apparna (iOS och Android). Den kostnadsfria provperioden börjar när appen öppnas och enheten registreras.

• LOGIN | CSV

  Skapad 12 Feb 2026

  Ett vanligt sätt att låsa material bakom en inloggningsprocedur är att använda en CSV-fil. När en läsare försöker logga in görs en kontroll mot registret (CSV-filen) som avgör om åtkomst beviljas eller inte. Vad ska registret innehålla? En CSV-fil ser ut som en Excel-fil och önskvärd information som den bör innehålla är:- Namn- E-postadresser- Kundnummer/abonnemangsnummer/ID-nummer Var ska registret sparas? The file gets uploaded to us by using a FTP-client. Filen laddas upp till oss med hjälp av en FTP-klient.Om du inte har en FTP-klient måste du ladda ner en, till exempel FileZilla.- Ladda ner FileZilla för Mac- Ladda ner FileZilla för Windows Kom ihåg att alltid namnge filen på samma sätt varje gång en ny fil skapas, så att vi alltid hittar den när vi importerar.

• 

  Hantera prenumeranter i Prenly Workspace

  Skapad 24 Oct 2025

  Det kan finnas flera anledningar till att en prenumerant ska raderas, till exempel GDPR. Oavsett anledning följer här en beskrivning av hur du kan radera en enskild prenumerant. Förutsättningar. För att radera en prenumerant måste du ha rollen Subscriber manager team membership på ditt team membership-konto. Steg 1. Logga in på Prenly Workspace. Steg 2. I menyn till vänster väljer du Prenly och önskad prenumerantkatalog som representerar Prenlys version av prenumeranternas information från det prenumerationssystem du valt. Välj abonnentkatalogen . Steg 3. Leta reda på den prenumerant som du vill ta bort från prenumerantlistan. Du kan antingen hitta abonnenten i tabellvyn eller filtrera resultatet genom att välja fältet Sök och ange sökvärden. Steg 4. Välj abonnentens abonnemangskonto i abonnentöversikten för att komma till vyn med detaljerad abonnentinformation där du kan administrera abonnenten. Välj abonnentens prenumerationskonto. Steg 5. I det övre högra hörnet, till höger om Abonnentinformation, väljer du Ta bort abonnent. Välj "Ta bort abonnent" för att ta bort abonnenten. Steg 6. Bekräfta borttagningen av abonnenten genom att välja Delete. Observera att du inte kan ångra borttagningen av en prenumerant när du har valt knappen Delete.Om du vill avbryta väljer du Cancel. Bekräfta borttagningen av abonnemangskontot för att ta bort abonnenten . Prenumerantens prenumerationskonto har tagits bort. Notera. Om abonnentkatalogen är kopplad till en integration eller en aktiv import kan abonnemangskontot automatiskt återskapas baserat på svar och information från importen/integrationen. Det är en god idé att kontrollera att prenumeranten har raderats från ditt prenumerationssystem. Hur är det med användarens inloggningskonto? Användarens separata inloggningskonto måste raderas av användaren. Användaren initierar processen genom att lägga till "/user/delete-account" till webbappens URL. Exempel. Givet att webbappen är tillgänglig på https://example.com/ besöker användaren https://example.com/user/delete-account för att initiera processen för att radera sitt inloggningskonto.

• Remote API

  Skapad 24 Oct 2025

  Syftet med detta dokument är att förklara: 1. ...hur Prenlys ekosystem gör det möjligt att hantera autentisering och auktorisering av användare med hjälp av en teknisk infrastruktur som ägs av utgivaren eller en tredje part. 2. ...hur en teknisk implementering kan göras genom att bygga ett modest rest-API som följer specifikationen "Prenly Remote authority API". Kontakt Vänligen kontakta oss via e-post på hello@prenly.com eller via telefon på +46-31-3884740 för frågor eller problem angående detta API. Definitioner Autentisering är processen att verifiera någons eller någots identitet, dvs. om de är den de utger sig för att vara, innan åtkomst till skyddade data beviljas. Normalt görs detta genom att tillhandahålla vissa referenser, t.ex. ett användarnamn och ett lösenord. Givet att uppgifterna matchar en lagrad post "verifieras" (autentiseras) användaren genom att tillämpa principen att användaren visste något som bara den "riktiga" användaren skulle veta. Auktorisering är den process där man bestämmer vilka resurser en användare har tillgång till, dvs. vilka data användaren har behörighet att komma åt och vad användaren får eller inte får göra. För Prenly innebär detta att bestämma vilka publikationer som användaren kan se och öppna för att läsa. Ett API(Application Program Interface)är en uppsättning rutiner, protokoll och verktyg för att hantera interaktionen mellan olika system eller delar av system, och dikterar kommunikationen mellan systemen. I Prenly är en auktoritet en teknisk implementering som bestämmer hur autentisering och auktorisering hanteras av en Prenly-applikation i Prenlys backend. Introduktion till Prenly Remote Authority API ger möjlighet att ersätta Prenlys hantering av auktorisering och/eller autentisering genom att implementera API-slutpunkter som följer en API-specifikation, vilket gör det möjligt för en Prenly-kund att autentisera och auktorisera utifrån sitt system, sina krav och behov. I grund och botten gör detta det möjligt för Prenly-applikationens myndighet att auktorisera och/eller autentisera användare när de interagerar med Prenly-applikationen, dvs. när de läser publikationer i en app, genom proxy av Prenly Remote Authority API. Prenly-myndigheten kommer att förmedla autentiserings- och auktoriseringsförfrågningar mellan användare och Prenly där ingen direkt kommunikation tillåts mellan användare och API-implementering. Istället informerar API-implementeringen Prenly-myndigheten om hur den ska agera på användarnas autentiserings- och auktoriseringsförfrågningar. Implementera ditt API Förstå hur användaren använder Prenly-applikationen Prenly-applikationer Prenly förser slutanvändaren med applikationer som främst används för att läsa publikationer och artiklar. Applikationen är antingen en inbyggd mobilapp på Android- eller iOS-plattformen eller vår responsiva webbaserade e-läsare. Dessa två applikationstyper erbjuder en liknande användarupplevelse. Applikationen kan innehålla publicerade publikationer som är offentliga för alla, samt skyddat innehåll som kräver någon form av tillstånd för att kunna konsumeras. För inbyggda appar är det också möjligt att låta alla icke-inloggade användare konsumera vissa publikationer gratis innan inloggning krävs. Navigera i applikationen När en användare använder applikationen kan han eller hon normalt se startsidan som innehåller komponenter som visar publicerade publikationer. Publika publikationer kan öppnas och läsas genom att välja publikationen. Men när användaren försöker öppna en skyddad publikation kommer programmet att kräva att användaren loggar in(autentisering). Efter inloggningen avgör Prenly om den begärda publikationen är läsbar för den användaren(auktorisering). Om så är fallet öppnas publikationen och är redo att användas. Om användaren inte har läsåtkomst meddelas användaren i appen. Det skyddade innehållet kommer inte att visas, men användaren kommer fortfarande att vara inloggad. I vissa fall kommer en applikation att kräva att användaren loggar in för att visa vissa publikationer, särskilt när inte alla publicerade publikationer kan ses av vem som helst. Till exempel publikationer som är tillgängliga via en prenumeration där andra publicerade publikationer som inte är prenumererade ska vara dolda. Konfigurera en API-miljö Förtroende för Prenly-förfrågningar Prenly skickar en fördefinierad hemlig nyckel i alla autentiserings- och auktoriseringsförfrågningar. Nyckeln är endast känd av Prenly och ditt system. Du bör kontrollera att den tillhandahållna nyckeln matchar den förväntade nyckeln för alla API-förfrågningar. Du kan också öppna upp dina API-slutpunkter för endast vissa IP-adresser för extra säkerhet. Kontakta oss för att få en uppdaterad lista över IP-adresser som Prenly kommer att använda i förfrågningar om du vill ha denna extra säkerhet. Kryptera trafiken Vi rekommenderar starkt att du inte tillåter någon okrypterad HTTP-trafik till ditt API. Använd HTTPS! Tillåt ett REST-liknande beteende Prenly-förfrågningar görs för närvarande med HTTP POST, men API:et bör inte vara begränsat till att använda några HTTP-metoder för framtida endpoint-expansion. Se den aktuella API-specifikationen för mer information eftersom API-specifikationen har sista ordet i eventuella avvikelser från denna dokumentation. I API-svar används HTTP-statuskoder för att informera Prenly om resultatet. Du måste kunna svara med olika HTTP-statuskoder, både för lyckade förfrågningar och för datafel, körtidsfel och oväntade serverfel. Parametrar för begäran skickas för närvarande som JSON i begärans kropp. Alla slutpunkter svarar för närvarande med JSON i svarskroppen. Bekanta dig med OpenAPI 3.0 API-specifikationen dokumenteras i en yaml-fil enligt OpenAPI 3.0-standarden (tidigare Swagger) och anger de tekniska aspekterna och kraven för API:et och varje slutpunkt, inklusive alla dataobjekt för begäran och svar. Autogenererad dokumentation finns på https://apidoc.prenly.com/remote-api/ och specifikationsfilen finns på https://apidoc.prenly.com/remote-api/spec/v1.3-specification.yaml. Gör gärna en kopia av specifikationsfilen och modifiera den till dina API-slutpunkter (URL:er) eftersom den autogenererade specifikationen innehåller generiska namngivna slutpunkter som referens. Med den här filen kan du enkelt bygga en testmiljö med färdiga verktyg som finns på https://openapi.tools/ (se avsnittet "Testing"). Läs mer om OpenAPI, inklusive specifikationen, på https://www.openapis.org/. Bygga slutpunkten för autentisering Se API-specifikationen på https://apidoc.prenly.com/remote-api/ för slutpunkterna för autentisering. Du kan välja slutpunktens URL precis som du vill, men slutpunkten måste följa API-specifikationen. Parametrar för begäran Begärandeparametrar är en del av begäran som JSON och skickas av Prenly för varje begäran. Svar vid framgång En lyckad inloggning måste svara med HTTP-statuskod 200 och ett JSON-svar med den unika identifieraren för den användare som autentiserades. Svar vid misslyckande Kända fel som beror på de angivna parametrarna för begäran måste svara med någon av HTTP-statuskoderna 401, 403 eller 412 enligt specifikationen i API-dokumentationen. Dessa fel måste innehålla ett JSON-svar som följer Error-datamodellen som du hittar längst ner på https://apidoc.prenly.com/remote-api/. Du kan välja att antingen tillhandahålla ett Error eller ett tomt JSON-objekt. För närvarande krävs endast egenskapen "message" om du tillhandahåller ett Error. Det är dock rekommenderat att även ange en "code"-egenskap. Vi rekommenderar starkt att du anger ett värde för egenskapen "message" på engelska som representerar felet på något sätt. Om din programvara har någon form av interna koder är det lämpligt att använda dem här om framtida ömsesidig felsökning kommer att behövas. Inkludera inte personuppgifter som inte behövs, t.ex. personnamn! Unika ID:n är tillräckligt bra för felsökning. Denna information visas aldrig för slutanvändaren men kan loggas i Prenly för att förenkla felsökning. Bygga slutpunkten för auktorisering Se API-specifikationen på https://apidoc.prenly.com/remote-api/ för slutpunkterna för auktorisering. Du kan välja slutpunktens URL precis som du vill, men slutpunkten måste följa API-specifikationen. Parametrar för begäran Begärandeparametrar är en del av begäran som JSON och skickas av Prenly för varje begäran. Svar vid framgång En lyckad hämtning av användarinformationen måste svara med HTTP-statuskod 200 och ett JSON-svar enligt UserSummary-datamodellen som beskrivs i specifikationen. Fälten i detta dataobjekt förklaras längst ned på https://apidoc.prenly.com/remote-api/. Vad egenskaper används till Den enda egenskapen som för närvarande inte kan lämnas tom är "uid". De andra egenskaperna kan utelämnas, men vi rekommenderar att du anger en "productCodes"-egenskap för att bättre kunna kontrollera om Prenly ska bevilja läsbehörighet till publikationer eller inte. För närvarande kommer Prenly att behandla en saknad "productCodes"-egenskap som en tom lista. Svar vid misslyckande Kända fel som beror på de angivna parametrarna för begäran måste svara med någon av HTTP-statuskoderna 403, 404 eller 412 enligt specifikationen i API-dokumentationen. Dessa fel måste innehålla ett JSON-svar som följer datamodellen Error enligt beskrivningen ovan. Testning Det är viktigt att testa din implementation för slutpunkterna för autentisering och auktorisering. Se https://docs.google .com/document/d/1UxmvDs7_Z0GwGbwCHXr4Ojpb9HaZif1nJ8YRMmztzeo/ för mer information om hur du testar dina endpoints. Vad händer i Prenly? När användaren loggar in (autentisering + auktorisering) När användaren begär att få logga in och skickar in inloggningsformuläret skickas inloggningsuppgifterna till Prenlys myndighet (krypterade med SSL). Därifrån hanterar myndigheten hur man använder dessa referenser för att autentisera användaren. För API:et Remote authority innebär detta att autentiseringsuppgifterna skickas till fjärranslutningspunkten enligt specifikationen. Prenly kommer att bearbeta API-svaret och hantera både lyckade och misslyckade autentiseringsförfrågningar där användaren kommer att se ett fel beroende på HTTP-statuskoden för felsvaret. Se nedan för mer information. Om autentiseringen lyckades... En lyckad inloggning kommer att utlösa en separat auktoriseringsbegäran till API-slutpunkten för auktorisering för att hämta användarens information, som cachas i Prenly under en begränsad tid. Applikationen kommer också att visa att någon är inloggad, med namn eller e-post baserat på vilka användardata som returnerades i användarinformationen. Om inloggningsuppgifterna var felaktiga... Om begäran var tekniskt framgångsrik, men autentiseringsuppgifterna var felaktiga, kommer Prenly-myndigheten att meddela applikationen och ett meddelande om felaktiga autentiseringsuppgifter kommer att presenteras för användaren. Om något misslyckades... Andra klient- eller serverbaserade fel, eller nätverksfel, fångas upp och loggas av Prenly. Programmet kommer att få ett lämpligt felmeddelande som presenteras för användaren. När användaren fortsätter att läsa Cachelagring för upprepade förfrågningar Cachelagring av svarsdata från en lyckad auktorisering (användarens information) eliminerar behovet av upprepade förfrågningar till fjärr-API:t för att hämta användardata som sällan ändras. Varje Prenly-kund kan välja utgångstid för cacheminnet, vi rekommenderar att du ställer in 30 minuter, där den minsta tillåtna utgångstiden för cacheminnet är 20 minuter. Återauktorisering Prenly kommer att använda det cachade resultatet för varje auktoriseringsbegäran så länge som cacheminnet inte har löpt ut. Om cachen har löpt ut kommer Prenly att utlösa en ny auktoriseringsbegäran till auktoriseringsslutpunkten i fjärr-API:t. Detta kommer att uppdatera användarens data, t.ex. produkttillgänglighet, samt de cachade data. Hantering av fel Om ett serverfel (5xx HTTP-kod) inträffar när omauktorisering utlöses förlängs utgångstiden för cachen med fem minuter. Prenly gör detta för att undvika att användare loggas ut på grund av tillfälliga nätverks- eller serverfel; användaren fortsätter att läsa som om inget hänt, och efter fem minuter görs ett nytt omauktoriseringsförsök. Detta beteende varar så länge som serverproblemet kvarstår. Prenly kommer att logga sådana tekniska problem och försöka nå kunden om detta inträffar. Att gå live När du tror att API:et är redo att tas i drift (du är klar med att utveckla och testa din implementering), kontakta oss för att ta de sista stegen. Prenly kommer att kräva information från dig för att konfigurera din implementering i Prenly. Informationen kommer att utvärderas och om allt är i sin ordning kan din implementering användas i Prenly för dina valda Prenly-applikationer för e-papper. Konfigurera Prenly Innan din implementering av fjärr-API:t kan användas i Prenly måste du tillhandahålla: - Din valda hemliga nyckel för slutpunkterna för autentisering och auktorisering - Dina valda API-slutpunkter - En lista över produkter som ska ge läsbehörighet och för vilka Prenly-titeln (endast Prenly-kända produkter i produktkodlistan från auktoriseringsändpunkten kan ge läsbehörighet) - Din önskade utgångstid för cachen - En URL där en ny användare kan skapa ett konto - En URL där en användare kan ta bort sitt konto - En URL där en användare kan återställa sitt lösenord (om de har glömt sitt lösenord) - Vi rekommenderar att du också tillhandahåller en URL där en auktoriserad användare utan några tidigare kända produktkoder kan aktivera en produkt (t.ex. köpa en prenumeration) - Användaruppgifter (användarnamn och lösenord) för testanvändaren, där användaren delas av Textalk, Apple och Google (om du har inbyggda appar) där minst en produktkod måste förbli aktiv så länge som fjärr-API:t används av Prenly-myndigheten för ditt e-papper