🥁First strategy #webinar of the year: 31 January❗ Join @kvantomme to learn about how to build your #strategy for c… https://t.co/pTIjAapD7s

Lead API Economist at API Academy
Because of PSD2 regulation, all EU banks are obliged to open APIs in a forced innovation context. Mehdi presents 8 different banking approaches to API portals (RBC, Teller, HSBC, Credit Agricole, BBVA, Deutsche Bank, Fidor, Capital One).
Top 5 demands developers and CTOs ask for
Takeaways
First talk at #apithedocs Paris is @medjawii talking about APIs in banking and their developer portals pic.twitter.com/46d0DBiBkE
— Kristof Van Tomme (@kvantomme) April 24, 2018
Our #API team is at @mozilla offices to attend @APItheDocs. @medjawii shares his experience about bank developer portal. #uxdesign pic.twitter.com/LMiY15PGkz
— dailymotionEng (@dailymotionEng) April 24, 2018
Technical writer at Pronovix
How can you inspire and motivate the developers who use your APIs to become advocates? In this talk, Kathleen takes us on a journey full of practical examples taken from 38 public-facing developer portals.
Developer portals have four main tasks to do:
Overall conclusion:
Take care of developer experience and documentation experience and your business will benefit from it.
What your API overview pages should answer @kat_deroo #APItheDocs pic.twitter.com/NIdGEwjhKX
— Taylor Barnett (@taylor_atx) April 24, 2018
Technical author at Microdec
What is a release note exactly? It's a documentation type: new features, bug fixes, change in the way features are to be used, known issues, upgrade paths (to the quickest way to the latest version), deprications.
Deprications are less often talked about. Software moves on, or some functions are not needed any more.
Semantics are important: bugfix or resolved issue?
API specific release notes:
Challenges for the technical writer:
Writing release notes forces communication, raises questions around business goals and technical testing. Brings home the need for documentation again.
Next is @Ken_Davies from @MicrodecPlc with a talk about release notes! #apithedocs #writethedocs pic.twitter.com/hVR7D1NO44
— Kristof Van Tomme (@kvantomme) April 24, 2018
Software developer (mostly PHP, some JS), technical writer, API consultant, and entrepreneur. Building CloudObjectsIO
Are SDKs really necessary, are they worth the cost and effort? What are the advantages for API consumers and for API providers?
Contra SDK:
Pro SDK:
Furthermore, Lukas explains:
The 4 patterns of an SDK strategy: provider-supported — community-contributed — consumer-driven — HTTP is the SDK,
Good SDKs design: API design first — open source is a must — make SDK development part of the API testing, "Respect the target platform's approach first, and the consistency within your API second",
The pros and cons of auto-generated SDKs: standardized approach vs not necessarily adding business-specific value,
How to document APIs and SDKs (approaches: API first, SDK second — SDK first, API second — integrated — tutorials vs references: take care of consistency) via examples taken from the Stripe, Twilio, Algolia, Sendgrid, AWS, and Google developer portals.
Takeaways:
"One strategy: what if HTTP was the SDK?", @LukasRosenstock at @APItheDocs Paris, @mozilla #API #APIthedocs
— dailymotionEng (@dailymotionEng) April 24, 2018
Developer Community Manager at Typeform
What goes on internally before launching a public-facing developer portal? What problems do you need to tackle? What are the implications of certain ideas and decisions? What comes next?
Goals: a solid suite of APIs, good reference docs, engaged developers
How?
Result:
The platform team becomes a separate business unit that reports directly to the founders and investors.
Not so obvious: learn how to approach developers (via marketing) — buy-in from leadership team — real-life testing (internal hackathon: engineers team up with non-engineers to test the APIs and the API docs) — depricate old APIs
Long-term plans: a platform team that manages all processes related to the developer platform — a developer portal beyond the API references — a DX model — focus on relations within the company to be able to push the product
Results of the first stage: A developer portal with API references and an SDK — get started section — troubleshooting — a basic community page
Plans: sandbox — open source docs (on GitHub) — changelog
Road improvements: developer relations — partnerships & integrations — innovation — feedback loop
Eva @1KHats totally rocked with her talk. So. Much. Useful. Info. Wow. #APITheDocs #apithedocsparis @APItheDocs pic.twitter.com/Myjo55lu4T
— Karen Sawrey (@krnswry) April 24, 2018
Director of content strategy at Worldpay
Lead API writer at Worldpay
Story continued from 2016 Agile the Docs conference.
Resources and budget from different stakeholders for a proper DX portal
Planning steps
Consolidation phase
New implementations for DX improvement
Technical details for DX improvement
Example roadmap for creating a consistent API experience with users part of the process #APItheDocs pic.twitter.com/ijgSf43cEa
— Taylor Barnett (@taylor_atx) April 24, 2018
Technical Writer at CossackLabs
Task: move 3 documentation sets from GitHub to their own servers
The main ready-made platforms have security issues that a cryptography company cannot afford to have, so they decided to set up their own docs server from scratch. Lots of documents, have to explain a lot before people are even ready to try the crypto part. Building the platform - collect references on what it should look like
Main problems and solutions
Here @krnswry making it easy and fun to understand the challenges of creating your own documentation server #apithedocs pic.twitter.com/0ULZKvaQxy
— Eva (@1KHats) April 24, 2018
Global Documentation Manager at KAL
The current situation
Best practices
Include:
Bridget provides us, throughout her talk, with hands-on examples and further references to dive more deeply into the topic of cybersecurity.
Security considerations for API docs - @khursheb pic.twitter.com/X0VzPPkHlt
— Kristof Van Tomme (@kvantomme) April 24, 2018
Lead Community Engineer at Stoplight
The OpenAPI Specification, a standard, structured approach for describing APIs, can be used for more than writing/generating reference documentation: you can also apply it for e.g. contract testing, prototyping, client SDKs. Taylor explains.
Self-documenting APIs do not exist, there will always be manual work:
Standardization helps, the OpenAPI spec as a collaboration tool:
The OpenAPI spec enhances DX:
Going to infinity: explore further what can be done with the help of OpenAPI, such as linting and style guides.
Going to infinity and beyond documentation with OpenAPI - by @taylor_atx from @stoplightio #apithedocs pic.twitter.com/p9D3ZiMejS
— Kristof Van Tomme (@kvantomme) April 24, 2018
Senior technical writer at MongoDB
Goal: automate the specification and concentrate talents in developing tutorials. This decision may look obvious in hindsight, but they had to do some research before coming to that conclusion: Writing for Scale: Streamlining API Documentation Maintenance
This talk describes the why and how of automatically generating your API specification.
In every tooling case, automation relies upon creating a YAML configuration file: routes, methods, parameters, error messages, and so on for each endpoint. Each tool provides editors, linters and the like to create and validate these files.
MongoDB chose Swagger: well supported and well adopted. Starting with an existing API with almost 200 endpoints across dozens of classes, there is not full automation to import. Swagger has:
Existing tools to generate the API specification file in six different programming languages With Swagger-Core, the docs team needs only to annotate the existing code (Jersey/JAX-RS for our REST API code).
Tech writer's development environments set up exactly as of their API developers', to enable working with the codebase in a manner consistent with their development practices.
An unexpected benefit of choosing to work within the API codebase: you learn how the code is organized.
For all further technical details –and there is a lot!– look up Anthony's slide deck, with speaker's notes.
Last talk of #apithedocs Paris by @atsansone from @mongoDB - Deploying OpenAPI within an Existing API pic.twitter.com/vMh9jKWXEQ
— Kristof Van Tomme (@kvantomme) April 24, 2018
Original recording of the conference by Kristof Van Tomme, Creative Commons Attribution Share-Alike License v3.0
🥁First strategy #webinar of the year: 31 January❗ Join @kvantomme to learn about how to build your #strategy for c… https://t.co/pTIjAapD7s
We're excited to bring you the new virtual sessions of #APItheDocs focusing on the importance of #feedback #metrics… https://t.co/ifmptrM2bk
The #APItheDocs Virtual series returns in January, focusing on what is worth measuring on the community side of do… https://t.co/hS5D5ZzGg0
💡What are the essential elements of #developerportals? 💡How do you build a strategy that creates and catalyzes grea… https://t.co/5xstaoMV2w