Hey everyone! As the summer winds down, we wanted to make sure we launched a very important feature of the platform. Since we first announced Build on Standard Library people have been asking, "how do I create my own Connector APIs?" We're pleased to announce that the process of building your own reusable APIs for use in setting up workflows is now a straightforward process. You can Build Your Own Connector APIs easily, and we even have a template to start.

Build Your Own Connector APIs

To build your own Connector API, we've provided a very easy template that you can deploy from GitHub using our Deploy from GitHub button. It's available on GitHub: stdlib-examples/connector-pokefusion.

The example is a Connector API that provides Pokemon Fusion capabilities, and can be used in any app you build. For example, our team has built a /pokefusion Slack slash command.

Pokefusion Dropdown

Pokefusion Result

To get started and implement your own Pokefusion API, head over to GitHub: stdlib-examples/connector-pokefusion. Follow the README and deploy directly from the example! You'll need to make sure you publish a version of the API before you see it available in the dropdown.

Changing an API to a Connector API

Additionally, any API you build on Standard Library can be changed between a Workflow API and Connector API from the project page. In order to appear in the Build on Standard Library UI, an API must both be classified as a Connector API and a version (release) must be published.

Simply click the lock icon to the right of the Connector API dropdown, and voila!

Select the project type and you're all done! Please note that Connector APIs can not respond to events.

Happy Building!

That's all this week, if you'd like help please feel free to join our Slack workspace for help from us and the community. You can also follow us on Twitter, @StdLibHQ.

More coming soon!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! I'm happy to have the opportunity to write another Standard Library update. This week we've added support for using Twilio as an event source! We've also released a couple of connector APIs for Twilio, which will help you send messages and manage phone numbers.

Twilio Event Source

We've added support for setting Twilio as the event source for workflows. Just select Twilio from the workflow editor and sms.received as the event to create a workflow that's triggered via SMS. Your workflow will be able to use the source phone number, the message text, and other information to respond in any way you'd like.

Event Source

We've written a tutorial on how to build a Twilio SMS hub to help you get started.

Twilio Connector APIs

We've also added two connector APIs to help you leverage Twilio in your workflows.

You can use these instantly on Build on Standard Library!

Twilio APIs on Build

If there are any other features of Twilio you'd like to see added please don't hesitate to reach out via email [email protected], or join our developer Slack Workspace for help (click here for an invitation).

Thank You!

Thanks for keeping up to date with the development of Build on Standard Library! If you'd like to keep up with the latest news, follow us on Twitter, @StdLibHQ .

Thanks for reading, we can't wait to see what you build!

Steve Meyer
Software Engineer, Standard Library

Hey everyone! I'm happy to be back this week with another Standard Library update. We've released a new guide on creating a Slack app that creates and applies Stripe coupons which we hope you'll enjoy! We've also shipped new connector APIs for Stripe and Slack.

Managing Stripe Coupons in Slack

We've created an easy to set up, fully customizable template of a Stripe coupon management Slack app! Like the last few guides, you can deploy your own version in just a few clicks by going to the GitHub repo and clicking the "Deploy" button in the README. We also published a more in-depth tutorial that walks you through the entire process.

You can open a dialog by typing /create-coupon, then when you hit Create, the app will create a coupon code that you can give to a potential customer or apply to an existing customer:

Dialog Message

Then, you can type /apply-coupon to open another dialog that allows you to apply a coupon code directly to an existing subscriber:


Slack and Stripe Connector APIs

We've also added a few new Slack and Stripe connector APIs for you to play around with:

Other Updates

  • Pricing page is now mobile friendly
  • Issues fixed around cloning actions within a workflow
  • Improvements around APIs that have not received requests for long periods of times

If there are any other features you'd like to see added please don't hesitate to reach out via email [email protected], or join our developer Slack Workspace for help (click here for an invitation).

Thank You!

Thanks for reading! If you'd like to keep up with the latest news around Build on Standard Library, follow us on Twitter, @StdLibHQ .

We can't wait to see what you build!

Jacob Lee
Co-Founder, Standard Library

Our announcement last week was Deploy from GitHub. It only seems fitting to announce that this week, we have added GitHub as an event source, as well as three GitHub connector APIs. We are all excited about the possibilities now that GitHub is a first-class citizen of the Standard Library ecosystem.

GitHub Event Source

We've added support for setting GitHub as the event source for workflows. Just select GitHub from the workflow editor and choose an event like pull_request.opened or issues.created.

Event Source

We've written a a tutorial on how to build a GitHub issue management system with Slack and Airtable. You can deploy it instantly from github: project-github-issue-slack-app using our new Deploy on Standard Library button! Here's a preview of what you get.


GitHub Connector APIs

We've also added three GitHub connector APIs, to help you integrate the GitHub ecosystem into your workflows.

You can use these instantly on Build on Standard Library!

GitHub APIs on Build

If there are any other features of the GitHub API you'd like to see added please don't hesitate to reach out via email [email protected], or join join our developer Slack Workspace for help (click here for an invitation).

Thank You!

Thanks for keeping up to date with the development of Build on Standard Library! If you'd like to keep up with the latest news, follow us on Twitter, @StdLibHQ .

Thanks for reading, we can't wait to see what you build!

Steve Meyer
Software Engineer, Standard Library

What a summer! We've launched a few connector APIs and tutorials, and we're happy to keep shipping content and feature releases. This week we're really excited to launch a new big addition to Standard Library, Deploy from GitHub. With Deploy from GitHub, Standard Library workflow templates are super easy to share with anybody without requiring them to manually set up workflows — just click our deploy button!

Deploy from GitHub

We've added a Deploy from GitHub button that anybody can add to their READMEs on GitHub projects. Simply visit deploy.stdlib.com for instructions, or add the following code snippet to any public GitHub repository:

[<img src="https://deploy.stdlib.com/static/images/deploy.svg" width="192">](https://deploy.stdlib.com/)

You'll end up with something that looks like this:

Deploy from GitHub in README

Using the GitHub Button to Deploy on Standard Library

To provide an example of deploying from GitHub, we've set up a basic Slack application that requires no coding to get started with — even to connect to Slack! You can visit the README here:

GitHub: stdlib-examples/project-slack-ping

Once you click the Deploy from GitHub button, you'll be brought to a screen that looks like this:

Deploy on Build

Simply click Link Resource and then Deploy Project to proceed! Note that you'll probably still need to create the /echo command on your Slack app, so please refer to the README for a quick primer on how to do so. You'll end up with your very own Ping bot on Slack!


Thank you!

That's all for now! We'll be leveraging Deploy from GitHub significantly as we continue to grow — expect another update shortly! As usual, If you'd like support from our community, please join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

😎 Keep it cool and keep building. Let us know what you come up with!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! This week we're introducing the Clearbit Connector APIs. These APIs include clearbit.person for finding out enrichment data about a specific person, clearbit.risk for calculating risk scores of a specific e-mail address, and clearbit.company for looking up specific company enrichment information.

Using the Clearbit Connector APIs

You can use the Clearbit Connector API by visiting build.stdlib.com/tokens and creating a General Use Token and linking your Clearbit account. It'll be available from the dropdown to link new resources on any token management page.

You can also add it when creating a new workflow. The authentication process simply involves copying your Clearbit public and secret keys to your Standard Library identity.

We've published a tutorial on how to build an Slack App that automatically enriches customer information for you from Stripe. It's called Build a Slack “New Customer” Notification App in 7 Minutes with Stripe, Clearbit, Standard Library and Node.js, check it out!

Thank you!

That's all this week — next week we'll have some brand new platform features for you, we're excited! As usual, If you'd like support from our community, please join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

😊 Happy building!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! Last week we covered the Google Sheets Connector API that can turn any Google Sheet into a database. This week, we're going to cover the introduction of one of our "launch" Connector APIs — the Airtable Connector API which connects directly to any Airtable base.

Similar to @googlesheets/query, @airtable/query allows you to query any Airtable base using the KeyQL specification making data queries simple, standardized and tractable across the SaaS applications and APIs you use on Standard Library.

A Quick API Example

Using the Airtable Query API in a project is as simple as...

const lib = require('lib')({token: process.env.STDLIB_SECRET_TOKEN});

const result = await lib.airtable.query['@0.1.11'].select({
  table: 'Events', // Your table name
  where: {Date__recency_lt: 3600} // KeyQL query, gets `Date` an hour ago or less
  limit: {count: 2} // KeyQL limit, limits results to 2

result.rows; // array of rows matching [{createdTime: 'x', fields: {Date: 'x', ... }}]

You can authenticate Airtable to any Standard Library identity on your Tokens Management Page. Create a General Use Token to use outside of Standard Library projects.

Build an SMS Event Notification System with Airtable

As a sample, we've prepared a tutorial of how you can use the Airtable API to build an SMS-based Event Notification System.

You can click here to read it — or enjoy this animated example!

Airtable Workflow

That's it!

Shorter update this week, we just wanted to fill you in on how you can start playing around with Airtable on Standard Library. We hope you enjoy! If you'd like support, please join our Slack workspace. You can also follow us on Twitter, @StdLibHQ. We'll have more for you next week, as usual.

Keith Horwood
Founder and CEO, Standard Library

Hey all,

It's been two weeks since we first launched Build on Standard Library and what a rush! We're excited to show you more of what Build can do. This week, we're officially announcing our Google Sheets query API that turns any Google Sheet into a queryable database. Simply link your Google Sheet when using build.stdlib.com or create a General Use Identity token and go nuts on the documentation page.

Before we get into the Google Sheets connector API, we just want to give a team shoutout to our favourite serverless engineer and pundit, Ben Kehoe, who threw his hat in for support.

Linking Google Sheets to a Standard Library Identity

As a connector API, we've custom-built the googlesheets.query API atop our Identity product to automatically authenticate you with a default spreadsheet when you use it. It relies on KeyQL to provide a simple query language atop your spreadsheet. To use it, first visit the tokens page on Build on Standard Library at build.stdlib.com/tokens. You should a page like this:

Note: All new users will automatically have a General Use Identity Token assigned. If so, you can skip the Token Creation step.

If you don't already have a General Use Identity Token (Legacy Tokens don't count), you'll want to click Create General Use Identity (Development). You'll get a prompt that looks like this:

Enter a name, such as My Dev Token, and click Create New Authentication Token. It'll show up on the General Use Identity Tokens list. Please note that free accounts only support one (1) General Use Identity Token, but it's ultra affordable after that — just $15 / mo for two more. You can contact us if you need more than that, we're happy to help!

Click on the name of either an existing token or the new token you just created to proceed, you'll be brought to a token management screen:

Find the Link Another Resource selector on the middle left. Select Google Sheets and the the plus [+] button.

From here, you'll have the option to Link a New Resource:

Click the Link a New Resource button and the Google OAuth flow will be triggered. Select the appropriate account...

And you'll see a progress indicator:

Once complete, you'll see a list of Google Sheets available to you. Choose one. Please note: The Google Sheets query API requires you to provide a range of values to turn into a Database. The first row will always be used as column headers.

Select the appropriate Google Sheet and click Finish to complete the process...

Voila! Your General Use Identity Token (perhaps named My Dev Token) is now linked to this sheet. You can change which sheet is linked any time from this page.

Using the Google Sheets Query API

Now that we've linked our Google Sheet, we can visit the Google Sheets Query API reference page. From here, scroll down to the select method:

On the selector on the bottom right, where it says Unauthenticated, select the token you just created (My Dev Token):

Fill in the range parameter with the range you'd like to turn into a Database, like A1:Z1000 (database will be truncated at first empty row). Now hit Run Function...

You should see a list of all results. In this example, we used a Spreadsheet from a Web Crawling / Scraping tutorial we've written.

You can now use this code in any codebase, or build with the Google Sheets API using Build on Standard Library!

That's all!

We hope you enjoy this Connector API. We're excited to get a lot more content out this summer, but the developers we've been working with have found it immensely valuable to work with Google Sheets as if it's a database. We agree, and are excited to see what you build with it!

As always, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ. Stay tuned for more updates!

Keith Horwood
Founder and CEO, Standard Library

Nine months. The time it takes from conception to development of a fully-functional human being with their own thoughts, feeling, hopes, dreams and ambitions. That's how long the Standard Library team has been working to develop the latest iteration of our product, Build on Standard Library. Today, we're excited to launch it to the world.

Introducing Build on Standard Library

Build on Standard Library, to put it simply, is workflow automation — similar in spirit to well-known products like Zapier — custom designed for developers, with professional engineering tools of the trade like environments, version control, rollbacks, the ability to build custom connectors using FunctionScript API schemas and more built-in. There are no black boxes, everything that you can build with our user interfaces is completely decomposable to code. Build, as we refer to it, is the culmination of tens of Hackathons, hundreds of customer introductions and interviews, and thousands of hours of developers both building and running APIs and workflows atop our API platform.

There's a lot we can say about Build, but this six minute demo video captures most of the product capabilities.

Why Build? A Brief History of Standard Library

The core mission of Standard Library has always been to make the web more programmable with APIs. Three years ago, in the summer of 2016, we realized there was something obviously missing from the World Wide Web. APIs, or more aptly, remote procedure calls, have never been given a formal definition as part of the Web's specification. As a result, the developer community has spent the past three decades iterating on server-side scripting technologies and interface patterns — SOAP, REST, GraphQL, OpenAPI, YAML configuration and more.

Serverless web technologies and the rise of Node.js made something readily apparent: for better or worse, the accessibility of JavaScript in the browser had opened up software development to a brand new cohort of developers. All you needed was a text editor and a browser. We surmised that the main consequence of the introduction of serverless architectures (no infrastructure management) would be the commoditization of back-end development, likely to herald the same sort of "Cambrian explosion" we saw in front-end development in the early 2000s that continues to this day.

This led us to begin work on Standard Library, a central registry for building, organizing, and executing APIs. After all — if we were likely to see an explosion in the amount of APIs being developed by a larger constituency of developers, we would need a way to organize them. There were two major problems with this thesis. First, we were effectively nobodies. Who would listen to us? Second, as we launched the first few iterations of our product it became clear that the largest problem we faced with adoption of our proposed "Standard Library" was developer and Enterprise inertia. The value proposition of automatically generated API docs combined with hosting may have been appealing as a corner of, say, the AWS or Azure cloud — but it was not turning heads coming from a meager team of two software engineers (myself and Jacob Lee).

So, we added another software engineer in the summer of 2017, Steve. And we worked tirelessly — somewhat behind the scenes — to recruit some of the most successful companies and individuals to our corner. Over the years we've received investment from the original author of RubyGems: Chad Fowler, Slack, Stripe, folks like Carter Rabasa who helped lead development of Twilio Functions, and many, many more. Our friends and supporters have been equally helpful in keeping us moving forward — Ahmad Nassri, CTO of NPM, Evan You, author of Vue.js, Ben Tossell, founder of MakerPad, and Romain Huet, head of Developer Relations at Stripe — to name just a few.

Build on Standard Library — Connecting APIs

We have always had and continue to maintain a strong belief in our mission. Our command line tools and even our in-browser editor weren't enough, we realized that if we were to succeed in "making the web more programmable" we would need to create a product that leverages the technologies we've built to make API composition orders of magnitude more accessible, especially to new entrants to software development. Some refer to this as the "low-code" movement, we simply see it as a natural progression of software development accessibility. Speaking to students at Hackathons and some of the most enthusiastic early Standard Library developers, we noticed that these new entrants to software development wanted to build software even though they were not necessarily industry professionals. We asked ourselves, "can we build something easy enough for anybody to use, but flexible enough for professional, and even Enterprise engineering teams?"

In response to this question, Build on Standard Library was truly born after a brief discussion with Patrick Collison, when he asked me why — given a free hour of time, of which he doesn't find often — the most difficult part of scripting against the Stripe ecosystem was finding the environment variables he needed to connect to all of their internal apps. Everything clicked. The following nine months led to the development of:

  • FunctionScript, a language and specification for turning Node.js functions into typed HTTP APIs
  • KeyQL, a simple query language that can be used to do things like turn Google Sheets spreadsheets into queryable databases
  • Identity Tokens, the federated identity (keychain) model of API accession that allows you to link multiple resources from different apps / APIs to a single key
  • Incorporation of RunKit's technology to be able to prototype and script without first shipping to a cloud platform
  • Leveraging FunctionScript schemas to automatically generate clean user interfaces

The first version of Build took five months to build, with three engineers. We had close to two years of platform development backing it. We started testing it with customers and users.

It was promising, but it kind of sucked. We realized that a lot of APIs (Google Sheets, as a prime example) were in no way actually designed for usability — they instead opted for flexibility, providing a robust but difficult to reason about interface, expecting keen software engineers to simply, "figure it the hell out." These keen developers were not representative of the most enthusiastic early adopters of our platform. So we started shipping our own APIs as abstractions on top of existing ones, following the design mantra of, "a non-developer has to be able to easily use this from a form-based interface, and a professional engineer has to still feel like it's flexible enough".

Four painstaking months later, and countless sleepless nights, we finally feel like we're able to deliver the seed of a product we can feel proud about.

So, at 3AM, from a hotel in Toronto that we haven't left all week, we're launching Build on Standard Library to the world.

You can check us out on Product Hunt → Build on Standard Library or simply visit build.stdlib.com to get started.

What's Next?

This is only the beginning. We have hundreds, thousands of API "connectors" to build. Our platform is open — while source code of APIs is not visible, anybody is free to publish an interface and host their code on our platform. To have your connector officially added, you need only ask us to verify that it is (1) not malicious and (2) ideally, officially sponsored by the corporate entity it's communicating with, if applicable. For now, we'll need to create an auth process for you manually. In the meantime, we'll be adding connectors ourselves, prioritized by company partnerships. You can expect to see the Slack and Stripe APIs fully supported, with new (some unannounced) partnerships coming soon.

You can get started with our Documentation if you want to know the ins and outs of our platform. We've set up a very permissive free tier for you to play with, it should not restrict your ability to develop upon us in any way.

  • Free, unlimited workflow projects
  • Free, unlimited steps in your workflows
  • Free observability with built-in logging and error detection
  • Free conditional logic as part of your workflows
  • Free version control and project history, including rollbacks
  • Free customization of any workflow, with code
  • Free general API and webhook development

Our paid tier starts at $15/mo and adds a few nifty features for the power users in the crowd:

  • Upgrade from 1 environment (dev) per project → unlimited environments
  • Upgrade from 3 additional collaborators per project → 5 additional collaborators
  • Upgrade from 3 Linked Resources per Identity → unlimited Linked Resources
    • Please see the Identity section in our docs for more details.
  • Upgrade from 1 General Use Identity Token3 General Use Identity Tokens
    • Please see the Identity section in our docs for more details.
  • Upgrade from $5.00 in available platform credits per month → $15.00
    • Supports roughly 750,000 × 100ms requests
    • Workflows are billed at an on-demand rate of $0.0002 per second while running, rounded to the nearest millisecond
    • There is a minimum billed time of 100ms per request
    • Some APIs you can connect with, like utils/sms, bill you per request made to them ($0.01 per request in this example).
  • Additional rollover credits can be purchased based on usage that roll over to your next month's balance (never overpay or force a tier upgrade)

Let us know what else you'd like to see from us at any time, and feel free to peruse pricing on our Pricing page.

Thank You

Before we let you go, we are of course compelled to let you know that we're hiring. E-mail us your resume. That e-mail, as it stands, gets directly forwarded to my inbox.

We hope you'll support us in our endeavour. It's ambitious, it will be difficult, but we want to make building software easier for everybody. We truly want to make the web more programmable.

Thanks for all of your support. It means the world. And, as always, happy building.

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! We've been on a roll these past few weeks. Two weeks ago we launched FunctionScript, our open source language and specification for building APIs. Last week, we added KeyQL to our roster of OSS as well to complement FunctionScript.

This week, we thought we'd take a little bit of a detour as compared to our normal modus operandi — we're very pleased to be able to release FunctionScript Server! FunctionScript Server is a simple example of using the FunctionScript Gateway to invoke Node.js Functions as strongly typed web APIs. For some of you, this may be interpreted as straying from our "serverless" roots — but in earnest, we've never really been a "serverless" company first, our focal point has always been on API interconnectivity. We're simply of the belief that the serverless computing paradigm is too powerful to be ignored, especially when it comes to its impact on API development and composition.

FunctionScript Server

FunctionScript Server is a simple Node.js server, instantly deployable to Heroku, that implements the FunctionScript Gateway to serve strongly typed Web APIs. The setup, locally, is dead simple:

$ git clone [email protected]:FunctionScript/functionscript-server.git
$ cd functionscript-server
$ npm install
$ npm start

The goal of the project was based on requests we had after the release of FunctionScript to show a working demo. While deploying FunctionScript APIs to Standard Library is straightforward, we felt that without showing an external ecosystem implementation we wouldn't be able to showcase the power of the FunctionScript specification.

API Endpoints

There are four API endpoints that serve different purposes to introduce you to the basics of FunctionScript


Reads ./pages/index.html and uses it as a simple HTML template. In this example, you're introduced to the {object.http} type for returning HTTP responses. The default response type is JSON.

const fs = require('fs');
const PAGE = fs.readFileSync('./pages/index.html').toString();

* This API endpoint simply serves a static HTML page.
*   It replaces all instances of `{%varname}` with corresponding GET / POST
*   parameters. The default is to respond to the `name` parameter
* @param {string} name A name to enter.
* @returns {object.http} response The HTTP response
module.exports = async (name = 'world', context) => {
  let render = PAGE.replace(/\{\%([\w]+)\}/gi, ($0, $1) => context.params[$1]);
  return {
    headers: {
      'Content-Type': 'text/html'
    body: render


Adds two numbers together with a hello message, returns JSON string. This example shows you the built-in FuncitonScript error-handling using required parameters.

* A simple API that adds two numbers together. `a` and `b` are required parameters
*   and the API will automatically throw an error if they are not provided
* @param {string} name A name to enter.
* @param {number} a The first of two numbers to add.
* @param {number} b The second of two numbers to add.
* @returns {string} message A simple hello mesage
module.exports = async (name = 'world', a, b) => {
  return `Hello ${name}, ${a} + ${b} = ${a + b}!`;


Uses utils/sms to send an SMS message. This example shows off a little of the power of Standard Library, a central registry of FunctionScript-powered APIs. You can obtain your own STDLIB_SECRET_TOKEN by registering on Standard Library.

const lib = require('lib')({token: process.env.STDLIB_SECRET_TOKEN});

* Sends an SMS using https://stdlib.com/@utils/lib/sms
* @param {string} tel A telephone number to send SMS to
* @param {string} body A message body to send
* @returns {object} result The result of the SMS
module.exports = async (tel, body) => {
  let result = await lib.utils.sms['@1.0.11']({
    to: tel,
    body: `Testing from FunctionScript Server:\n${body}`
  return result;


Routes static resources from ./static/ directory based on pathname. This is a comprehensive example that reads from multiple different folders and serves different HTTP headers ("Content-Type") based on the filenames it's serving. It is also an introduction to the __notfound__.js handler.

const mime = require('mime');

const fileio = require('../../helpers/fileio.js');

let filepath = './static';
let staticFiles = fileio.readFiles(filepath);

 * This endpoint handles all routes to `/static` over HTTP, and maps them to the
 *  `./static` directory (part of the root dir)
 * It is a special example of a "NOT FOUND" handler, which any request not
 *   matching an existing functions/ API endpoint will be routed to
 * `context.path` can be used to retrieve the path name
 * @returns {object.http}
module.exports = async (context) => {

  // Hot reload for local development
  if (process.env.NODE_ENV !== 'release') {
    staticFiles = fileio.readFiles(filepath);

  let pathEnd = context.path.slice().pop();
  let staticFilepath = context.path.slice(1).join('/');
  let file = pathEnd.indexOf('.') !== -1
    ? staticFiles[staticFilepath]
    : (
      staticFiles[[staticFilepath, 'index.htm'].filter(v => !!v).join('/')] ||
      staticFiles[[staticFilepath, 'index.html'].filter(v => !!v).join('/')]

  if (!file) {
    return {
      statusCode: 404,
      body: '404 - Not Found',
      headers: {
        'Content-Type': 'text/plain'

  let cacheControl = process.env.NODE_ENV === 'release'
    ? 'max-age=31536000'
    : 'max-age=0';

  return {
    statusCode: 200,
    body: Buffer.from(file),
    headers: {
      'Content-Type': mime.getType(staticFilepath),
      'Cache-Control': cacheControl

That's it this week!

More coming on the developer tools and product side! Stay tuned next week.

As usual, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

Hey again! It's only a been a week since we announced FunctionScript, and the repository is nearing 1,000 GitHub Stars already! We're very grateful for the attention FunctionScript has been able to generate, and we're excited to keep rolling.

This week we're announcing another core piece of the Standard Library API development platform — KeyQL. While FunctionScript simplifies API development by uniting the code you write with the HTTP interface, KeyQL allows you to define logical queries of datasets using only JSON key-value pairs. It is the perfect complement to imperative API development and represents a way to add simple yet robust querying capabilities to existing APIs.

You'll begin to understand the power of KeyQL as specification in the coming weeks as we release more of the platform and new products.


KeyQL Logo

KeyQL is a language, specification and package for querying datasets using key-value pairs. It is heavily inspired by the simplicity and ease-of-use of Django and similar ORMs. The provided Node.js package can be used to filter large JSON datasets from within any codebase, but the primary purpose of KeyQL is to be used with FunctionScript APIs, where JSON or HTTP Query Parameter key-value pairs can be used to encode query requests to underlying datasets.

KeyQL is meant for easy querying of JSON datasets, spreadsheet data, information retrieved from APIs such as Airtable and more. It can be used to add robust querying capabilities to existing APIs without a massive architectural lift and shift.

The motivation for KeyQL differs from that of GraphQL. KeyQL is intended to provide a simple querying interface to existing imperative APIs and relatively flat datasets. The operators (comparators) are the most important feature and are meant to be easily interpretable by even the newest developer. KeyQL and GraphQL can, in theory, coexist within a single codebase or API implementation. KeyQL is not intended to be used to define an entire backend architecture and provides no opinions on the graph-based structure of output data (you do not define schemas with it).

Quick Example

A quick example of using KeyQL with a FunctionScript API would look like:

Filename: /dataset.json

    "id": 1,
    "fields": {
      "name": "Alice",
      "birthdate": "12/01/1988",
      "pets": 2
    "id": 2,
    "fields": {
      "name": "Bernard",
      "birthdate": "11/11/1972",
      "pets": 5
    "id": 3,
    "fields": {
      "name": "Christine",
      "birthdate": "01/05/1991",
      "pets": 0

Filename: /functions/__main__.js

const KeyQL = require('keyql');
const dataset = require('../dataset.json');
// Searching through the "fields" object in each row
const kqlDataset = new KeyQL(dataset, row => row.fields);

* Query a dataset based on an Array of Objects
* @param {object.keyql.query} where A list of fields to query for
* @returns {array} result The result list
module.exports = async (where = {}) => {

  return kqlDataset.query()
    .select([where]) // Wrap in array if provided a raw object


An HTTP POST request containing:

  "where": {
    "pets__gt": 3

Would return:

    "id": 2,
    "fields": {
      "name": "Bernard",
      "birthdate": "11/11/1972",
      "pets": 5

Writing Queries

Writing KeyQL Queries is as simple as preparing a JSON Object. For example, in a dataset that has records that look like...

// Example dataset in JavaScript
    first_name: 'Dolores',
    last_name: 'Abernathy',
    is_host: true,
    eye_color: 'blue',
    hair_color: 'blonde',
    location_in_park: null,
    age: 250

You could write a query against it that returns...

Query: All entries with first_name = Dolores

    "first_name": "Dolores"

Query: first_name = Dolores AND eye_color in blue, green

    "first_name": "Dolores",
    "eye_color__in": ["blue", "green"]

Query: first_name = Dolores OR first_name = Teddy

    "first_name": "Dolores"
    "first_name": "Teddy"

Supported Operators

All operators in KeyQL queries are preceded by a __ delimiter. To reiterate from the previous section, this means you can query the field first_name with;

"first_name" // (default to "is" operator)

Full List of Supported Operators

The following table assumes that queryValue is the value you're searching for provided a specified key, and entryValue is the matching entry in a dataset.

Operator Behavior
is Finds all matching entries. Returns entryValue === queryValue (exact match, type included).
not Finds all non-matching entries. Returns entryValue !== queryValue (exact match, type included).
gt Finds all entries greater than specified value. Returns entryValue > queryValue.
gte Finds all entries greater than or equal to specified value. Returns entryValue >= queryValue.
lt Finds all entries less than specified value. Returns entryValue < queryValue.
lte Finds all entries less than or equal to specified value. Returns entryValue <= queryValue.
contains Finds all entries containing the exact provided value. Works when entryValue is a string or an array.
icontains Finds all entries containing the provided value, case-insensitive. Works when entryValue is a string or an array.
startswith Finds all entries starting with the exact provided value. Works when entryValue is a string.
istartswith Finds all entries starting with the provided value, case-insensitive. Works when entryValue is a string.
endswith Finds all entries ending with the exact provided value. Works when entryValue is a string.
iendswith Finds all entries ending with the provided value, case-insensitive. Works when entryValue is a string.
is_null Finds all entries where entryValue === null, queryValue is ignored.
is_true Finds all entries where entryValue === true, queryValue is ignored.
is_false Finds all entries where entryValue === false, queryValue is ignored.
not_null Finds all entries where entryValue !== null, queryValue is ignored.
not_true Finds all entries where entryValue !== true, queryValue is ignored.
not_false Finds all entries where entryValue !== false, queryValue is ignored.
in Finds all entries within the provided value, intended to match when queryValue is an array but works with string input.
not_in Finds all entries not in the provided value, intended to match when queryValue is an array but works with string input.
recency_lt Finds all entries where DATE(entryValue) is recent within less than queryValue in number of seconds. i.e. "field__recency__lt": 3600 would look for entries that have field as a date/timestamp within the past hour (exclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
recency_lte Finds all entries where DATE(entryValue) is recent within less than or equal to queryValue in number of seconds. i.e. "field__recency__lte": 3600 would look for entries that have field as a date/timestamp within the past hour (inclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
recency_gt Finds all entries where DATE(entryValue) has a recency greater than queryValue in number of seconds. i.e. "field__recency__gt": 3600 would look for entries that have field as a date/timestamp outside the past hour (exclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
recency_gte Finds all entries where DATE(entryValue) has a recency greater than or equal to queryValue in number of seconds. i.e. "field__recency__gte": 3600 would look for entries that have field as a date/timestamp outside the past hour (inclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
upcoming_lt Finds all entries where DATE(entryValue) is going to occur within less than queryValue in number of seconds. i.e. "field__upcoming_lt": 3600 would look for entries that have field as a date/timestamp within the next hour (exclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
upcoming_lte Finds all entries where DATE(entryValue) is going to occur within less than or equal to queryValue in number of seconds. i.e. "field__upcoming_lte": 3600 would look for entries that have field as a date/timestamp within the next hour (inclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
upcoming_gt Finds all entries where DATE(entryValue) is going to occur within greater than queryValue in number of seconds. i.e. "field__upcoming_gt": 3600 would look for entries that have field as a date/timestamp outside the next hour (exclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
upcoming_gte Finds all entries where DATE(entryValue) is going to occur within greater than or equal to queryValue in number of seconds. i.e. "field__upcoming_gte": 3600 would look for entries that have field as a date/timestamp outside the next hour (inclusive). ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
date_lt Finds all entries where DATE(entryValue) is less than DATE(queryValue), i.e. '12-06-1988' < '01-01-2019'. ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
date_lte Finds all entries where DATE(entryValue) is less than or equal to DATE(queryValue), i.e. '12-06-1988' <= '12-06-1988'. ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
date_gt Finds all entries where DATE(entryValue) is greater than DATE(queryValue), i.e. '12-06-1988' > '01-01-1980'. ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.
date_gte Finds all entries where DATE(entryValue) is greater than or equal to DATE(queryValue), i.e. '12-06-1988' >= '12-06-1988'. ISO8601 Timestamps suggested, if no timezone entered UTC will be assumed.

Read More

You can read more about KeyQL on the GitHub repository, FunctionScript/KeyQL. We encourage you to contribute to development with thoughts and feedback.

Still More Coming

KeyQL is the second major release after FunctionScript, and is just another step in a complete overhaul of Standard Library's available tooling and the ecosystem we've been building. As usual, stay tuned.

If you're as excited as we are, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

Hey all, I have some exciting news. Nearly three months ago we announced we were working on something new. Today, we're breaking our silence and announcing a complete overhaul and re-launch of the Standard Library platform. This re-launch will be rolled out incrementally, beginning with our developer tools. However, over the next few weeks our announcements will touch everybody from backend API developers to spreadsheet pros, serverless pundits, code newbies, even "low-code" fanatics.

After speaking with thousands of folks ranging from students at hackathons to existing users and customers, IT professionals, Slack application builders and more, we identified a pretty significant opportunity to create a large amount of value for developers: specifically newbies. The heart of the problem we identified is that API development is largely inaccessible to a huge swath of professionals who could and should be able to make use of them on a daily basis. The modern API development stack is extremely intimidating — you don't just need to understand how to code, you need to understand frameworks, HTTP requests, hosting a server, and more.

We started out as a "serverless" company, but we believe "serverless" is but a small sliver of the overall opportunity ahead of us in this industry. If we can provide the right tools to new and emerging developers, we can change how people think about building software altogether. With this in mind, we have been busy rethinking Standard Library from the ground up. We will be presenting the changes to our platform and updates incrementally, starting with developers and moving up the stack as we go.

We're thrilled to kick off our series of announcements by introducing the world to FunctionScript, a language and specification for turning JavaScript functions into typed HTTP APIs. Some of what's included in this announcement can also be read directly on the FunctionScript GitHub repository.

FunctionScript Overview


FunctionScript is the primary specification underpinning our API development and integration platform. It allows JavaScript (Node.js) functions to be seamlessly exported as HTTP APIs by defining what the HTTP interface will look like and how it behaves - including type-safety mechanisms.

FunctionScript arose out of a need to introduce developers with little programming experience, but familiarity with JavaScript, to full-stack API development and best practices around defining and connecting HTTP application interfaces. For this reason, the goals of the language are significantly different than TypeScript. FunctionScript is intended to provide an easy introduction to API development for those of any skill level, while maintaining professional power and flexibility.

You can start building with FunctionScript immediately using Code on Standard Library, right in your web browser.

Quick Example of a FunctionScript API

The following is a real-world excerpt of an API that can be used to query a Spreadsheet like a Database. The underlying implementation has been hidden, but the parameters for the API can be seen.

* Select Rows from a Spreadsheet by querying it like a Database
* @param {string} spreadsheetId The id of the Spreadsheet.
* @param {string} range The A1 notation of the values to use as a table.
* @param {enum} bounds Specify the ending bounds of the table.
* @param {object} where A list of column values to filter by.
* @param {object} limit A limit representing the number of results to return
* @ {number} offset The offset of records to begin at
* @ {number} count The number of records to return, 0 will return all
* @returns {object} selectQueryResult
* @ {string} spreadsheetId
* @ {string} range
* @ {array} rows An array of objects corresponding to row values
module.exports = async (
  spreadsheetId = null,
  bounds = 'FIRST_EMPTY_ROW',
  where = {},
  limit = {offset: 0, count: 0},
) => {

  /* implementation-specific JavaScript */

  return {/* some data */};


It generates an API which accepts (and type checks against, following schemas):

  • spreadsheetId A string
  • range A string
  • bounds An enum, can be either "FIRST_EMPTY_ROW" or "FULL_RANGE"
  • where An object
  • limit An object that must contain:
    • limit.offset, a number
    • limit.count, a number

It will return an object:

  • selectQueryResult
    • selectQueryResult.spreadsheetId must be a string
    • selectQueryResult.range must be a string
    • selectQueryResult.rows must be an array

Why FunctionScript?

You can break down the reason for the development of FunctionScript into a few key points:

  • Modern developers and people being introduced to software development for the first time are often trying to build web-native scripts. It is exceedingly difficult to go from "zero to API" in less than a few hours, writing code is just the first step of many. We'd like it to be the first and only step.

  • No true standards around APIs have ever been built or enforced in a rigorous manner across the industry. Primarily, opinions around SOAP, REST and GraphQL requests have been built into frameworks and tools instead of a language specification, which has artificially inflated the cognitive overhead required to ship functional web-based software.

  • Companies like Stripe and Twilio which have built and enforced their own API development paradigms internally have unlocked massive developer audiences in short timeframes, indicating the power of treating web APIs as a first-class citizen of development.

  • Serverless computing, specifically the Function-as-a-Service model of web-based computation, has made API development significantly more accessible but has not brought us over the "last-mile" hump.

  • JavaScript, specifically Node.js, is an ideal target for API development standardization due to its accessibility (front-end and back-end), growth trajectory, and flexibility. Most new developers are introduced to JavaScript out of necessity.

  • As opposed to something like TypeScript, FunctionScript helps newer entrants to software development by extending JavaScript with very little overhead. It adds types around only the HTTP interface, leaving the majority of the language footprint untouched but strengthening the "weakest" and least predictable link in the development chain: user input.

With FunctionScript, it's our goal to develop a language specification for building APIs that automatically provides a number of necessary features without additional tooling:

  • Standardized API Calling Conventions (HTTP)
  • Type-Safety Mechanisms at the HTTP -> Code Interface
  • Automatically Generated API Documentation

FunctionScript: Roadmap

In the coming months we'll be doubling down on our investments in FunctionScript as the basis for the Standard Library Platform. You can expect to see:

  • A deeper integration to treat stdlib.com as the Standard Library for FunctionScript ("APIs"), available via the lib package on NPM
  • A growing, open-source, globally accessible Type System that will allow contributors to define their own custom types
  • Better, more sophisticated tooling for both newbies and professionals
  • An increased commitment to the development community

Much, Much More Coming

FunctionScript is just the first step in a complete overhaul of Standard Library's available tooling and the ecosystem we've been hard at work creating. Stay tuned for a heck of a lot more. It looks to be an exciting summer.

If you're as excited as we are, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! This week's update is going to be a little different than you're used to. Instead of announcing feature updates, we're going to keep it short and announce that we're working on Something New.

The team has been extremely hard at work on a new product which just entered Early Access Beta last week. More details will emerge soon and we're shipping new features at an unprecedented cadence, however, they're not public... meaning the blog updates here may get a little spotty at times.

What's coming, exactly? You'll have to wait to find out. 😁

What does this mean for you?

  • Everything that's coming next is additive — you will not be expected to change existing workflows
  • We will not be deprecating or changing core platform functionality in any major way
  • Following, there are no migrations necessary for the upcoming Beta
  • You can keep building on Standard Library exactly as you do today, those methods of building will not change now or in the future
  • Blog updates on stdlib.com/blog are, until at least the end of Q2 2019, not guaranteed on a bi-weekly cadence

If we've piqued your curiosity, you can feel free to e-mail us to ask about joining the new Early Access Beta.

That's it this week!


As usual, if you have any questions, support or otherwise, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! Scott here again with another batch of visual updates to the site. Just over a month ago I posted about our redesign, and this blog update follows the progression of those changes.

You can view the updates to our website here... feel free to follow along!

Last time I talked about some of the high level motivations for our website changes and about design as an iterative process. This means that all design is a work in progress to some extent, with milestones and versions. In this update, I want to talk about the ways in which this plays out from version to version. In this case I want to talk through how a site design evolves in terms of subtractive and additive changes.

Subtractive Changes — Decluttering

new home screen

Sometimes you have too much information, or the information is too dense and needs to be simplified or spread out so that it can be more easily digested. It can also be that you've just got too much decoration that doesn't help deliver the message any clearer. In the previous iteration of the site, I added a lot of lines and dots to try and drive home this idea of "connectivity". For me it felt more decorative than anything, and left portions of the page feeling cramped in some spots as well. The header icons were also pretty over the top in terms of screen real estate, so those were pared back. As a designer it's really tempting to over-emphasize the things that make a design pretty rather than the things that make it an effective communication tool.

Additive Changes — More Information

feature carousel

Sometimes, as a side effect of trying to simplify a design, we actually lose information. By trying to maintain a concise message we actually lost some important information about useful features Standard Library provides. To solve this we added a new feature carousel! Standard Library boasts a lot of really cool features, some of which are not immediately obvious at first glance. The carousel we added helps highlight those high level features without crowding the screen with a bunch of dense information. You're able to pick apart each one individually, without introducing a ton of vertical space. Now we get the best of both worlds: lots of great information, delivered in bite size chunks over time.

Thanks for reading!

Working through this push and pull between adding more, or saying more with less is an essential part of finding that sweet spot in your design. As always, we love to hear your feedback! Feel free to reach out on Twitter — @threesided

If you'd like to connect, please feel free to join our Slack workspace or follow us on Twitter @StdLibHQ.

Scott Gamble
Graphic Design and Engineering, Standard Library

Hello again everyone! This week at Standard Library, we're excited to announce something that's been cooking for a while — we're officially migrating to a new API Gateway beginning today. We've updated the FaaSlang spec to include some awesome new features and we'll be moving everybody's APIs to api.stdlib.com from lib.id, the current Gateway domain. More on what that means for you in terms of features and actions you may have to take below.

Before we jump in to that, we want to give a quick and big shoutout to both nwHacks 2019 and QHacks 19 which we were very pleased to be able to sponsor over the last two weekends. Between the two events we saw nearly 1,000 student attendees, and the projects built with Standard Library were phenomenal. Thank you for having us!

New API Gateway

As of today — February 6th, 2019 — all new APIs deployed to the Standard Library platform using our Command Line Utilities or Code on Standard Library will be given a new web address on [username].api.stdlib.com. This API Gateway is running version 0.4.0 of FaaSlang, our Gateway specification that performs type coercion, schema validation and more.

New API Gateway Features

  • Functions may no longer be called with Arrays or lists of parameters that map to function arguments — they must be invoked using an object of key-value pairs representing parameter names and values

  • As a result of this change, the first parameter in a function can now be of type any or object, reducing frustration for developers who want to pass in objects as the first (or only) parameter

  • Functions now support Object Schemas which can define specific key / value expectations in both type array and type object

Object Schemas

Standard Library API endpoint functions could previously be documented to be type-coerced and type-enforced based a modified ESDoc implementation, i.e.

* My API endpoint does something!
* @param {string} name
* @param {number} age
* @returns {string}
module.exports = async (name, age) => {
  return `Hello ${name}, you are ${age} years old`;

With Object Schemas, you can now accept object types and nest expected parameter values. Note that Objects can be overloaded and that a schema represents the minimum (smallest) object signature the function will accept. For arrays, Only one top-level value may be supplied and it must match every entry. In the example below, the friends array is an array of string types.

* My API endpoint does something!
* @param {object} person
*  {string} name
*  {number} age
* @param {array} friends
*  {string} friendName 
module.exports = async (person = {}, friends = []) => {
  return `Hello ${person.name}, you are ${person.age} years old.` +
    `You have these friends: ${friends.join(',')}`;

Migration Period

All of our developers and customers to date are currently using the lib.id gateway, but new developers will be directed towards api.stdlib.com immediately. For those using lib.id for webhooks, integrations and more — we're setting an End of Life target for October 6th, 2019, or eight months from today. Note that the old Gateway will no longer be receiving feature upgrades and improvements. Old functionality will remain the same, but if you're looking for new features we encourage you to reference the new Gateway. Your APIs will be available on [username].api.stdlib.com/[service]@[env] instead of [username].lib.id/[service]@[env].

If you've been connecting to Standard Library APIs with our lib package in Node.js or from your browser, you can simply upgrade the package to the most recent version 4.0.0 and the Gateway hostname will be updated automatically.

Thanks, and Happy Hacking!

Thanks for reading, and we hope you enjoy the new Gateway and features! You'll be seeing many more updates in the coming weeks. If you have any questions, support or otherwise, feel free to join our Slack workspace. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! We have another progress update for you. This week, we've updated the Code on Standard Library UI to be a little more explicit and friendly for developing and shipping APIs. Special thanks to the team at Stripe who helped by specifically requesting some of the features.

Before I get to the updates, I wanted to give a special shoutout to UofTHacks VI, University of Toronto's student Hackathon. Over 500 students showed up for 36 hours of hacking and we were happy to be able to help 20 teams in their quest to build the best hack. The team that walked away with five Nintendo Switch consoles for best use of Standard Library was Sharescription, a product that allows you to manage your shared house's subscriptions by splitting and collecting payments and then generating a virtual credit card to pay each provider (Netflix, etc.). Fantastic work!

Now, updates...

Code on Standard Library UI Updates

First we've changed the buttons on the bottom of the Code on Standard Library web interface to be a little more clear. We've added subtitles that explicitly describe what each button does, and we've renamed Publish to Up (deploys your API) to more closely map to our command line tools.

New Buttons

Next, the functionality of the Up (previously Publish) button has changed. It used to publish an immutable, versioned API immediately. We've now changed it to allow you to specify which mutable environment or immutable release version target you'd like to deploy to. Note that for free accounts, only the dev mutable development environment can be deployed to. Versioned deployments (releases) follow semver rules.

Code Deploy Prompt

Finally, when deploying APIs with Code on Standard Library from this flow, you'll be given an immediate link to both your API documentation and the root endpoint on the API itself (mapping to functions/__main__.js).

Code Deploy Result

That's it for the UI updates this week.

Play in Your Browser

You can play with this functionality by visiting code.stdlib.com directly, or we've embedded it for you below. Please note that the Run functionality will automatically deploy (if necessary) and execute the code you've written, allowing for continuous integration from the browser. As an often overlooked feature, you can also change execution parameters on the left of the Debug screen instead of using something like the Postman web application to manage HTTP requests. Cheers!

Thank You

As usual, thanks for the entire Standard Library team! We hope you enjoy. We invite you to join our Slack workspace if you'd like to chat with the community. You can also follow us on Twitter, @StdLibHQ.

Keith Horwood
Founder and CEO, Standard Library

It's that time again — another update! This week we're launching a small but useful API quite a few of our developers have asked for, the utils.screenshot API for capturing screenshots of websites programmatically, built atop Chrome's puppeteer headless browser implementation. As a Standard Library API it's easy to combine it with other APIs and features of the platform, like scheduled tasks. I'm excited to show it off!

Screenshot API

The API, available as utils.screenshot, exposes one endpoint and is ready to use with almost no configuration. It's as simple as:

const screenshot = require('lib').utils.screenshot;
let results = await screenshot({url: 'stdlib.com', screenSize: 'desktop'});

Like all APIs on Standard Library, it's easy to integrate utils.screenshot with other APIs. For instance, utils.mms. The mms API requires a URL that points to some picture. You can just reference the screenshot API and send screenshots right to your phone:

await lib.utils.mms({
  to: number,

You can test out the API from the documentation page, or from Code on Standard Library (embedded below, but you can open a new tab from that link). Click "run", and after a moment you should see the Standard Library main page appear in the results panel.


If you follow the API Endpoint URL, you can also open the image in a new tab. Please feel free to play with the API using Code on Standard Library embedded below!

That's All!

As usual, thanks for reading. If you have ideas for integrations or need help, join our Slack workspace or ask us on Twitter @StdLibHQ.

Steve Meyer
Software Engineer, Standard Library

Hey, Scott here with another update from the Standard Library team! If you've been checking out the Standard Library site over the last few months, you may have noticed that things have been looking pretty different. As our product evolves, our visual language has to evolve with it. Today we're launching the latest iteration of our design, so I thought I would take some time to talk about all the changes and the reasoning behind the look.

homepage header

I usually like to start with some high-level, abstract ideas. These can be anything from a generic shape, a mood, an idea, or, (more often in my case) a cheesy one-liner or pun. From the shortlist I had, the ones that stood out were Connecting the Dots and Bits and Blobs. These are what would guide the visual flair of the page. In the case of this design, this translated into dots, lines, and square bits.

As a designer, I want to communicate the company and product visions through brand visuals. One of the primary goals of Standard Library is making connections, both literally and figuratively. We provide a solution for connecting APIs with one another, and in doing so, connecting your applications with your data, colleagues and customers quickly and easily. Some of our customers' most frequent use cases are building integrations with Stripe, Slack, GitHub, Typeform and more. This is the connective tissue that runs through the entire product, so it made sense to reflect this in the design.

connecting the dots

Standard Library is all about simplifying complicated technical work and abstracting it into small, digestible pieces. A big part of working this design has been cutting away the fluff and working towards sticking with a core set of principles. The layout is uncomplicated, and all about getting to the meat of what we have to offer.

Design really is as much of an iterative process as engineering, and it's not often you get to peek behind the finished product or hear about why things end up looking the way they do. We're looking forward to continuing to deliver on the look and feel of our products as much as we do the technology behind them. If you're interested to hear more, feel free to reach out directly on Twitter — @threesided.

Be sure to take a look around and admire the new digs, even the revamped profile page... we'd love feedback around what you'd like to see next!

new profile hotness

Thanks for reading!

If you'd like to connect, please feel free to join our Slack workspace or follow us on Twitter @StdLibHQ.

Scott Gamble
Graphic Design and Engineering, Standard Library

Hey everyone! I'm happy to provide another update on behalf of the Standard Library team. This week we released a highly requested feature — the ability to view and tail logs directly from Code on Standard Library.

Logs from Code on Standard Library

We also had some fun this weekend traveling to the University of Western Ontario to help out at HackWestern. This was our second time at HackWestern, and we were absolutely blown away with the projects built on top of Standard Library. Unfortunately, there can only be one winner, so I'd like to give a special shout out to some new Nintendo Switch owners, AI Royale!

Thanks again to everybody who participated, to Western, and to the organizers. Now, on to the product update!

Logs from Code on Standard Library

We've been receiving a lot of feedback from the community around logging. Notably, a robust way to monitor and capture logs has not yet been available from Code on Standard Library. We're happy to say that changes today! Though tailing logs has previously been available through our dashboard and CLI, we've now added them to the Code on Standard Library web interface. You can view them by clicking on the "Logs" button on the toolbar at the bottom of the screen.

Once open, you can filter logs by type, environment, and API endpoint. We've included a sample for you to try out, embedded below. Just click "Run" and check out the logs!

We are always happy to work on quality of life improvements like this, so if you have an idea, please drop us a line!

That's All!

As usual, thanks for reading. If you'd like to connect, please feel free to join our Slack workspace or follow us on Twitter @StdLibHQ.

Steve Meyer
Software Engineer, Standard Library

Hey everyone! I'm happy to provide another update on behalf of the Standard Library team. The big news this week is that we released a solution for use as a persistence layer inside of Standard Library APIs. Simple key-value storage that's easy to set up has been one of our most requested features, and I'm excited to show it to you!

From a community standpoint, we also had the pleasure of traveling to New Jersey last weekend to help out at Hack Princeton. It was our third time at HackPrinceton, and it's always a pleasure to be able to work with such talented and driven students from all around North America. I would like to give a special shout out to the winners of our prize, TextNet and Hoot, for a couple of really creative, and well executed, projects.

Thanks again to everybody who participated, as well as Princeton and the organizers. We had a fantastic time. Now, on to product updates!

Key-Value Storage

Because all APIs built on our platform are stateless, we often get questions about configuring persistent storage for use in more complex applications. We are happy to announce that we now have an in-house solution, in the form of a simple key-value storage API. The API is available as utils.kv exposes a simple interface and is ready to use with no configuration. It's as simple as:

const kv = require('lib')({ token: process.env.STDLIB_LIBRARY_TOKEN }).utils.kv;
await kv.set({key: 'key', value: 'val'});
let results = await kv.get({key: 'key'});

All Standard Library accounts have a table automatically associated with them, tied to their username. Right now, users are restricted to a single table as we roll out the feature, but you'll have the ability to use more in the future. You can try it from the documentation page, or from Code on Standard Library (embedded below, but that link opens it in a new tab).

That's All!

As usual, thanks for reading. If you have questions or need help join our join our Slack workspace or ask us on Twitter @StdLibHQ.

Steve Meyer
Software Engineer, Standard Library

Hey everyone, another week, another update! This'll be a short one, seeing as our last update was last week and we're moving a little bit faster than our traditional bi-weekly updates. However, we're happy to announce two major additions to Standard Library: we've added automatic code completion, and with the official switch for Node 10.x to LTS we've bumped our Node engine (runtime) to 10.13.0 on all Standard Library APIs.

Automatic Code Completion

Code Completion on Standard Library

With the recent introduction of e-mail autocompletion to Gmail, we decided we'd like to add an autocompletion engine of our own to Code on Standard Library. If you weren't already aware, Code on Standard Library is a bespoke in-browser development experience built from scratch (literally the ground up) by our team; we don't use Microsoft's Monaco which is based off of VSCode, we rolled our own.

Because of this, we're missing a lot of the "freebies" some in-browser development environments get for free with VSCode. We're determined to make sure this doesn't stay the case for long; Code on Standard Library currently has a minified payload about 25% the size of Monaco and has a bunch of additional UI features re: creating tasks, loading from templates and more.

Right now, the code completion engine supports about 60 different predefined patterns that should help you get started with building APIs using Node in your browser: we plan to expand it to be a more robust "intellisense"-like experience. You can play with it below!

Node 10

Now that Node 10.x has gone LTS, we've upgraded the Standard Library code execution platform to run Node 10.13.0 from Node 8.x. Not much else to say here, we hope you enjoy having the most recent runtime features available!

That's it!

That's all this week. As usual, thanks for joining us on our journey, and if you have questions or need help join our Slack workspace (click for invitation) follow us on Twitter, @StdLibHQ, or feel free to reach out directly to me on Twitter, @keithwhor.

Happy building!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! I'm pleased to be back with another Standard Library update.

To begin with, we're announcing a pretty big change in branding. With the success of Code.xyz, we're pleased to give it a new place on Standard Library. As of today, Code.xyz is now Code on Standard Library. We've moved it to a new URL, code.stdlib.com, and the old code.xyz domain now acts as a redirect to the new domain.

A little background: at the end of May we announced an investment from Stripe and launched Code.xyz, our in-browser API development experience. This was an experiment — a hypothesis — that we could introduce more people to API development if we made it as easy as possible from the web. We're pleased to announce that this experiment was successful. Developers, old and new alike, are now building APIs with the same frequency from the web as they are from our command line tools. To work towards standardizing (no pun intended) our products and features, we felt the move to code.stdlib.com was the right thing to do.

Along with this change, we've shipped some helpful new features: our editor now helpfully underlines complement braces, we've upgrades to our build (package installation) system, and we've added a much-requested feature: log access for collaborators you've added to your API.

We're also excited to announce that we've added two new members of the Standard Library team: Eileen Zhong and Scott Gamble!

Welcome to the team! Now, let's get into the update.

Underlined Complement Braces

As a general quality of life improvement, we've upgraded the code.stdlib.com rendering engine to underline complement brackets. Stay tuned for more rendering engine upgrades, there's more that's been refactored under the hood and this complement braces support is just the beginning.

Underline complement braces

Build System Upgrades

We've made two significant improvements to our build system:

  1. Code on Standard Library now supports imports for paths within NPM packages, such as const lodash = require('lodash/fp') for the functional programming variant of the popular lodash package.

  2. We've upgraded and are now using NPM 6 for package installation in our build engine, resulting in faster build times for large packages. Note that we already cache package installations, so subsequent deployments of an API within a short timeframe should go blisteringly fast as usual.

Collaborator Logs

In addition to being able to edit and deploy new versions of APIs, users with API collaborator access to an API can now see logs for it directly from code.stdlib.com or from their command line.

You can add collaborators, as well as grant or restrict access in other ways, via the Share button on your API's documentation page or directly from code.stdlib.com.

That's It!

We hope you enjoy these new features –– you can try them out right now at https://code.stdlib.com, or simply use it embedded below:

If you have any questions or feedback, come talk to us in our Slack channel! You can receive an invite by clicking here. We're also available on Twitter, @StdLibHQ, and you can follow me directly @Hacubu. Stay tuned for more exciting updates in the future!

We can't wait to see what you'll build!

Jacob Lee
Co-Founder, Standard Library

Hey everyone! Another Wednesday, another update. It's the start of the fourth quarter and we have a busy few months lined up for you in regards to building APIs with Code.xyz. Two weeks ago we brought you Scheduled Tasks right from your browser, and our very own Steve Meyer published an article on how to Deliver New xkcd Comics to Your Phone Daily with Node.js, Standard Library Tasks, and Code.xyz.

That said, we've been receiving quite a bit of customer feedback that testing API endpoints from the browser can feel a little cumbersome: it's difficult to switch between files to have to go test an endpoint, especially when you're working with an endpoint that has multiple dependencies (relies on other files). We're listening, and we've had the same frustrations ourselves. This week we're excited to bring you a brand new, upgraded API running and debugging workflow right from your browser.

Running API

Before we get into the product updates, we'd like to give a brief shoutout to both Functions 18 Conference in Toronto where I had the opportunity to give the keynote presentation, and Confront in Malmo where we had an amazingly warm welcome to a Code.xyz workshop we ran.

Thanks again for everybody who attended!

Upgraded API Running and Debugging

With the newest iteration of Code.xyz we've turned debugging API endpoints from your functions/ folder into a truly first-class citizen of the in-browser development experience and we've moved some things around.

  • We've removed Parameter Editing from a right-handed sidebar to the new Debugger on the bottom of the screen
  • In addition, we've updated logging in the Debugger to be a better experience that keeps track of function execution history

Parameters and Logging

  • We've also changed how running API endpoints works
    • There's a new endpoint selector beside the Run button
    • By default, the status is linked (green link icon)
    • This means that as you change which API endpoint file you're in (in the functions/ folder), the Debugger will automatically switch to the correct endpoint
    • If you choose a file that is not in the functions/ folder, the endpoint selector will lock on the last modified endpoint
    • If you click the endpoint pin (green link icon) you can manually select which endpoint you'd like to run
    • to re-link the selector to your file selection, simply click the endpoint pin once again
  • Additionally, we now inline API endpoint call responses in your logs to maintain session records as you play with Code.xyz
  • Check the .gif below for examples of the above features in action!

Running API

  • Finally, we've changed how markdown previews work: any file that's identified as a markdown document will be given a preview in the bottom right of your editor, you can expand it by click the eyeball icon in the bottom right

Markdown Preview

That's it!

As per usual, if you'd like to play with the new features then head on over to code.xyz/?sample=t to load a sample project, or simply play with the editor inline as a part of this blog post below:

We hope you enjoy the new features, they should make API iteration and development a heck of a lot smoother. If you have any questions, please don't hesitate to come join our Slack workspace (click for invitation), follow us on Twitter, @StdLibHQ, or feel free to reach out directly to me on Twitter, @keithwhor. Always appreciate great feeback!

Happy building.

Keith Horwood
Founder and CEO, Standard Library

Hey everyone, I'm excited to have the opportunity to announce another update on behalf of the Standard Library team!

This past week we added scheduled task support to Code.xyz. Scheduled tasks have a huge variety of applications -- checking a webpage for daily changes, sending SMS reminders, creating a weekly dump from a database, and more. Regardless of your use-case, it's never been easier to schedule function executions, either with a simple interval (minute, hour, day, week) and frequency, or with a cron expression.

In other news, we are headed to Functions 2018 in Toronto at the end of this week. If you're in the area, make sure you stop by and say hello!

Schedule Tasks (API Execution) from Code.xyz

Scheduled task management is now available from Code.xyz. You can find the scheduled tasks integration right next to the Code tab, in the top-left corner of the screen.

Once there, you'll see all of your active tasks running on the left. To create a new task, pick an API from the selector on the right side of the screen.

Then you pick the endpoint (should your API have more than one), give the task a name and specify when you would like to run your task. Scheduling is quite flexible -- simply specify an interval, frequency, and start time (once a minute, twice an hour, four times a day, every Friday at 5PM), or, for more complex timing, use a cron expression. You can find documentation for cron syntax here.

Click Schedule Task - and you'll see your new task appear in the left panel!

If you would like to stop a scheduled task, you can remove it by clicking on its respective trash bin icon in the left panel.

Thank You!

As always, we appreciate your continued support and hope that you discover some solid use-cases for scheduling APIs! If you would like to contact us, please feel free to join our Slack workspace, or follow us on Twitter, @StdLibHQ.

We can't wait to see what you build!

Steve Meyer
Software Engineer, Standard Library

Hey everyone! It's Jacob from the Standard Library team with another bi-weekly update.

I'm pleased to announce support for directly sharing your APIs to email addresses, cold start mitigation for members of our team subscription plan, and improvements to scheduled task management from our CLI.

A few months ago, the team also attended ServerlessConf in San Francisco, where our founder and CEO, Keith, gave a talk about Standard Library and where we want to head from here. It went live recently, and it's definitely worth a watch:

We'll be headed to Functions 2018 in Toronto next week, so if you're in the area, come say hi! And now, without further ado, let's dive into the platform updates!

API Sharing to Email

It's now easier than ever to share APIs you build on Standard Library. Simply enter your friend or co-worker's email address, and we'll send them an invitation to check out your API! They'll be able to choose which Standard Library account they'd like to use to access your API, and you can set whether you'd like to allow them to just view your API's documentation or view and collaborate on the code itself.

You can still search for users by their Standard Library usernames, and you can even mix types of invitations within the same share.

Cold Start Improvements

We're happy to announce API cold start mitigation as a feature for users on our team subscription plan. This automatically applies to all of a user's deployed APIs, and should ensure that first executions of APIs after a long period of time will be faster.

Scheduled Task CLI Improvements

Scheduled task creation from the CLI now supports cron expressions and invocation of APIs deployed to development environments (i.e. @dev). Simply use the lib tasks:create command with the name of the API and follow the prompts.

Additionally, listing your tasks with lib tasks will show when your task will be invoked next.

Thank You!

We appreciate your continued support, and hope that you find these improvements helpful as you create your APIs! If you would like to contact us, please feel free to join our Slack workspace, or follow us on Twitter, @StdLibHQ.

We can't wait to see what you'll build!

Jacob Lee
Co-Founder, Standard Library

Hey all! I'm thrilled to announce another bi-weekly update from the Standard Library team.

We've added Code.xyz authentication support so you can test private or authentication-reliant APIs from your browser as you iterate on them, stack traces to runtime errors for dev APIs to aid debugging, and a feature allowing you to download your API's code as a tarball directly from Code.xyz.

We also traveled to Canada last weekend to help hackers at HackThe6ix, Toronto's leading summer hackathon. We met some amazingly talented, enthusiastic people, and saw some awesome projects built on the platform!

Let's dive in!

Authentication From Code.xyz

You can now select a library token you'd like to use to make authenticated requests directly from Code.xyz. This makes it simple to test access-restricted APIs, and/or APIs that require information like the username of the requester, right from your browser! Simply hover over your username in the top right of the editor and select Set Active Library Token:

You can see what your currently active token is, change your active token by clicking a different token in the menu, or unset your token if you'd like to make unauthenticated requests by clicking the same token you have set.

If you'd like to create a new token or expire one of your existing ones, simply follow the Manage Tokens button in the bottom of the dialog, or go to the library tokens section of your Standard Library dashboard.

Try it out below!

Stack Traces for Dev APIs

To help debug tricky issues, we've added visible stack traces to any API that's called in a non-release (i.e. development) environment (for example, dev). This information is available via an additional field in the error object returned by Standard Library error responses, stack (accessible from our client libraries as err.stack). For example, executing the following API:

Will now result in the following error:

Errors that released (i.e. versioned, 0.0.0, 0.1.0, etc.) APIs throw will not return the stack field, but are still available in your service's API logs.

Code.xyz Tarball Export

You can now download your API code directly from Code.xyz! After opening your project, simply right click its header in the file explorer and select Export as Tarball.

Thank You!

That's all for this week's update — we hope you find these features and improvements useful as you build! If you need to contact us, please feel free to join our Slack workspace, or follow us on Twitter, @StdLibHQ.

We can't wait to see what you'll build!

Jacob Lee
Co-Founder, Standard Library

Hey everyone! Welcome to another bi-weekly update from the team at Standard Library. This week we have something special for you: we've updated the API Project browsing and Source (template) finder on Code.xyz. We've also managed to knock out a few long-standing bugs, and made a few usability improvements. Excited to show you!

Before we get to that, we'd like give a really special thank you Murshid Hassen (@MurshidHassen) for his kind words this week — we've been working really hard to ship updates and every piece of receptive feedback makes the team feel awesome!

Again, thank you! If you enjoy using our products, feel free to let us know on Twitter.

Code.xyz Updates — Bug Fixes, New Project UI

Bug Fixes and Usability Improvements

  • Fixed a bug where fonts would be resized on orientation change (iOS)
  • Added the ability to "create a folder" (creates a directory with a single empty file)
  • Added previously released Share API Dialog to Code.xyz
  • Added the ability to direct link APIs with ?service= parameter
  • Moved Publish button into actions bar at bottom of API editor

New Project UI

We've updated our Project / Source (Template) management UI for a better landing experience on Code.xyz.

Our Old Project Finder was a pop-up dialog...

Old Project Finder

And our New Project UI is a full landing page experience, with integrated source loading as well.

New Project UI

If you'd like to check it out yourself, you can visit Code.xyz in your browser, or simply check out the embed below. Please note: on smaller screen sizes there's a <> Projects and <> Sources button to switch between interfaces, including in this embed.

Thank You!

That's it for this blog update, we hope you enjoy playing with the new UI! As we continue to bring API collaboration front-and-center you'll see more of a focus on sharing and API sources (templates), this is just the beginning. As usual if you need to contact us, please feel free to join our Slack workspace.

Happy building!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! Steve here from Standard Library. I'm excited to make the first non-founder post on our blog! While we've promised an update at least once every two weeks, we've been firing on all cylinders since ServerlessConf San Francisco. It's only been a week since our last update, but we're so excited about what we're working on we wanted to get it to you as fast as possible.

I am happy to introduce two new features to Standard Library and Code.xyz — improved error tracing for better observability of your APIs running on our platform as well as a brand new project selection and management interface. Here it all is!

Enhanced Error Tracing

Newly deployed APIs on Standard Library now automatically log error stack traces and full messages to aid debugging. This is especially useful for testing and gaining visibility into webhooks, where you are not testing your function directly from Code.xyz or your command line.

For example, calling the following API:

buggy api one

Will result in the following logs:

buggy api one stack

The stack trace extends to other files too. For example, this API:

buggy api two

Results in these logs:

buggy api two stack

Both normally thrown or returned errors and uncaught exceptions will show up in your function logs, which are available from your Standard Library dashboard or from your command line. You can check out the docs for full details here.

Updated Project Management

When autosaves were added to Code.xyz a few weeks ago, we noticed that the current way of selecting projects was becoming a bit cluttered. We updated the project selection window to group every version of a service together including autosaves, development APIs and released APIs. You can find the new finder by hovering over your username in the bottom left corner of Code.xyz and clicking Open Existing API.

new project finder location

Once your projects load, you can click or arrow through to expand a service. It will display all available versions that you can fetch, sorted by the last time that version was updated. For instance below, you can see that I have access to several versions of Code.xyz available to download (did you know that Code.xyz was built on Standard Library?).

new project finder

If you would like to check out the new UI yourself, feel free to play with an embedded version of Code.xyz below!

Thank You!

As usual, thanks for taking the time to read our updates! You'll start reading updates from more of our team as we continue to grow. If you're looking for a new role, please don't hesitate to check out our careers listing. Stay in touch with us by joining our Slack workspace, or follow us on Twitter, @StdLibHQ.


Steve Meyer
Software Engineer, Standard Library

Hey everyone! Today we have a special update and release live from ServerlessConf San Francisco. Since launching API Permissions two weeks ago the team has been hard at work iterating on our latest feature: improving the API Sharing (permission enabling) workflow for your Standard Library APIs built with our command line tools or Code.xyz.

To start with, we're super excited to be sponsors of ServerlessConf San Francisco this year. The event has been fantastic, with hundreds of developers from across the world coming to visit and chat about the future of serverless web technologies. We're very grateful to be working in this space with such amazing people! Here's a peek of the Hackathon we helped with on Sunday:

Without further ado, we're also thrilled to show you what we're rolling out this week!

Share APIs

We've updated our API Permissions dialog and menu to enable you to share APIs with other developers or within your organization more easily. You'll notice our old Manage Permissions button has been replaced with a Share button on any API page you own.

Share APIs

Upon clicking this button, you'll be given two options: you can invite somebody to execute your API and view documentation or collaborate on the underlying code.

Dialog Example

Execute API and View Documentation

This flow is intended for read-only (and execute-only) access to your API: for example, clients or partners you're iterating on an API with and need feedback from. You don't want these people to worry about the code and implementation of the API, but would like them to be able to use and play with your API.

View API Docs Options

You can choose to share this API with everyone (creates global, public access — not restricted to a Standard Library account) or add specific users. Further, you can decide which development environments this applies to. API releases are immutable, versioned releases of your API and are encouraged to be shared, but development environments should typically only be shared with clients or people you're working on your API with, you don't always want to share how the sausage is made!

You may also notice an Advanced button, with which you can use to set more granular permissions like restricting access to a specific IPv4 address or range and controlling execute / view documentation access separately.

Once you've shared your API via this mechanism, e-mails will be sent to Standard Library developers that you've granted permissions to. You'll also be redirected to global access management which looks something like this:

Access Management

Access refers to Execute, View Documentation and Deployment privileges and Scope refers to the types of APIs available: release only, or development environments as well.

Collaborate on Underlying Code

This flow is intended to invite teammates and other developers to collaborate on your API code. They'll be given access to the underlying API implementation, have full access to both API execution and documentation, and be able to access your API using Code.xyz.

Collaborate on Code

Once selected, these developers will be invited to modify and work on your API with you. Think of this like inviting people to work on a Google Doc with you with full modification privileges. For those of you that have used Standard Library and Code.xyz at hackathons, this is the easiest way to collaborate with any sort of team member without explicitly creating a team account. Have fun! You can play with Code.xyz and build your own Standard Library API below:

Thank You!

As usual, thanks for taking the time to read our updates, and thanks for being part of our journey at Standard Library! We're very happy to have you with us and have such great support from our growing developer community. Stay in touch with us by joining our Slack workspace, or follow us on Twitter, @StdLibHQ.

We look forward to building more with you!

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! It's that time again. It's been two weeks since we launched API Autosave as a part of Code.xyz, saving a lot of developers from losing the API building they'd be doing in their browser if they forgot to deploy. Today, we're launching a feature that should help people building Slack applications and more that want to restrict their API usage to a subset of IP addresses and / or authenticated users.

Introducing API Permissions

  • API permissions allow you to delegate access control on a per-API basis within Standard Library
  • These apply to APIs built from the Command Line or Code.xyz
  • The interface is available from both our dashboard and individual API pages on Standard Library
  • You can enable permissions, per user, IP (IPv4 address) or both to the following granularity;
    • API Execution: Can execute the API from the HTTP(S) endpoint or using SDKs
    • Documentation: All of the above, can also read documentation on Standard Library for the API
    • Deployment: All of the above, can also retrieve code and deploy new versions of the API using our CLI or Code.xyz
  • The default for permissions based on user type are as follows:
    • All users, all API development environments: API Execution
    • All users, all releases (unpublished): API Execution
    • All users, all releases (published): Documentation
    • All members of an organization, all APIs: Deployment
    • Owner, all APIs: Deployment
  • Basically — if you're part of an organization or own an API, you have Full Access (Deployment), otherwise you can only see published releases
  • All APIs on the platform are accessible via HTTP(S), ACLs used to be configurable as a deployment feature, we've now turned this into a platform feature

Enabling Permissions from Standard Library

Manage Permissions Button

  • Click to add permissions...

Manage Permissions

  • In the top section you'll have the ability to Select a user, Select an IP range, what Permission Level you're enabling, and Environments the permission applies to (releases or development environments)
  • By creating a permission entry, you whitelist the specific user x ip x permission x environment combination

Enabling Permissions from the Dashboard

  • Visit your dashboard API services page
  • Select your API that you'd like to modify the permissions of
  • Follow the steps above with the dashboard interface

Dashboard Permissions

Community Updates

Reflection: ServerlessDays London

In other news, we had the wonderful opportunity to speak and show off Code.xyz as ServerlessDays London just over a week ago. Thank you to everyone who showed up, it was a wonderful event!

Upcoming: ServerlessConf San Francisco

We also think it's a great time to mention we're sponsoring ServerlessConf San Francisco! Come join us on July 29th at the Hackathon where we'll be giving away prizes or throughout the conference from July 31st, 2018 until end of the day on August 1st, 2018. We'll be giving away free t-shirts and swag as well. Looking forward to seeing you!

Thank You!

Thanks for keeping up to date with Standard Library and Code.xyz development! If you'd like to keep up with the latest news, follow us on Twitter, @StdLibHQ and if you're looking for help don't hesitate to join our developer Slack Workspace for help (click here for an invitation).

Thank you for reading and being a part of our journey,

Keith Horwood
Founder and CEO, StdLib

Hey everyone! As promised, we're committed to keeping our community updated on a bi-weekly cadence by 9AM PT on Wednesday mornings. The last two weeks have been a flurry of activity for the Standard Library team — last week I was in Reykjavik, Iceland to present at BlueYard's Future of Software Development Conference, this week we'll be at ServerlessDays London, and on top of that, there have been some recent festivities for our North American friends and colleagues. July 1st was Canada day, and now that today is the 4th, happy Independence Day to our American community!

We've gotten off to quite a celebratory start this week. Following that excitement, we're happy to talk to you today about a very important update to Code.xyz. Since the launch of Code.xyz last month, we've had a few developers lose their API development progress by navigating between pages or hitting "back" in the web browser accidentally with no way to recover their work. We've now fixed this problem — at the popular request of our community, we've added a brand new cloud-based API autosave feature. In addition, we've also added the ability to delete existing APIs from within the Code.xyz API selection screen.

Code.xyz Feature — API Autosave

  • All API projects you work on via Code.xyz will now be autosaved every time you hit the orange "save" button in the bottom right

  • This feature replaces the previous behavior of being a local, temporary save only
  • You can load autosaves from the "Open Existing API..." prompt, which shows any actively deployed (and live) APIs, along with cloud autosaves at the top

  • We've also added the ability to delete both APIs and autosaves from this prompt — be careful, this cannot be undone!
  • To remove an API, simply right-click it in the "open existing API..." dialog

Try it out!

Here's our embedded sample API. You can try out API autosave by changing the file in any way you'd like and hitting Save in the bottom right. You can then try to open your Autosave by going to your user menu in the bottom left and hitting "Open Existing API..." — the autosave should appear at the top.

Thank You!

We hope you enjoy — we have a lot more coming, and we'd love to hear your feedback. Drop us a line any time on our community Slack workspace (click for an invitation). To the thousands of developers building APIs with us since we've launched Code.xyz, thank you!

Happy to have you with us,

Keith Horwood
Founder and CEO, Standard Library

Hey everyone! As promised in our last blog post, it's been two weeks, so it's time for an update on the progress of both Code.xyz and Standard Library. We are thrilled to be able to share that we hit a milestone earlier this week, more than 50,000 APIs have now been deployed to Standard Library — both using our command line tools and Code.xyz. These include Slack bots, Stripe stores, Messagebird's SMS APIs, everything you need to know about mountains via AscenDB's API, and tens of thousands of private workflow automation APIs (task scheduling, e-mail outreach, web scraping, you name it)!

If you've heard about Code.xyz and what we're doing at Standard Library but have no idea where to get started, our very own Janeth Ledezma Sanchez has you covered:

Now — the good stuff! Our community Slack workspace has been buzzing. There are all kinds of feature requests we've been itemizing and knocking out with a lot of interest around GitHub integration. We're pleased to announce that we've been listening and working hard to make Code.xyz a more integrated experience with your existing developer tools and workflows.

Code.xyz and Standard Library Updates

Export API Functions as GitHub Gists

  • Functions for APIs as Components: Export as GitHub Gist
    • We now offer the ability to export any individual function in your functions/ directory (API endpoints) as a GitHub Gist
    • This feature effectively turns functions / API endpoints into shareable components
    • You can use this functionality to share Code.xyz examples with others, or keep your own set of commonly used endpoints to mix-and-match in future API projects
    • This functionality is easily accessible by right-clicking the function you'd like to export from the TreeView or right-clicking the active file contents in the editor

Export as GitHub Gist

Import from GitHub Gists

  • Import from Gist: Load from URL
    • Once you have a gist, you can share it with others by sharing the link code.xyz/?gist=username/gistid0000 (where gistid0000 is the automatically generated unique gist id provided by GitHub)
    • The example below (and embedded at the bottom of this blog post) is located at https://code.xyz/?gist=keithwhor/6ad11a67add5860a75b0e8b0e3694af9

  • Import from Gist: Load from your Gists
    • By right-clicking in the Code.xyz TreeView, you can add any Gists you'd like to a project that you've previously saved from Code.xyz
    • These Gists can be used as "API function templates" or components as described above

Import Functions

Import Functions Dialog

API Documentation Introductions Made Easy: API.md

  • Platform Update: API.md
    • We've separated out internal and external documentation for your APIs into an API.md and README.md file
    • README.md is information for internal API development - you can share secrets around implementation details here
    • API.md is for end-users that you want to consume your API - it is used to generate documentation (namely, the API description and how to) on Standard Library

Thanks — try it out!

Want to try out our new features? Check out the example below: it's loading a Gist from my GitHub account that proves that [a == 1, a == 2, a == 3] can return [true, true, true] in JavaScript!

Thanks for reading, and stay tuned for more GitHub integrations!

Keith Horwood
Founder and CEO, StdLib

Last week we launched Code.xyz, the online code editor for building APIs to an amazing response — more than 2,500 APIs have been deployed using it in less than a week — and from everyone on the StdLib team, we wanted to say thank you. We're excited to build the future of serverless API development and collaborative coding with all of you!

Our post on Product Hunt skyrocketed to #2 Product of the Day, competing against new products from both Google and Intercom, and the announcement of our $2M fundraise from Stripe was well-received: I appreciate the personalized e-mails many sent in response. It means a lot, and we are very thankful to have such an awesome community of developers and supporters.

With that in mind, it's been six days since Code.xyz went live and we're on a roll — we're rapidly absorbing as much developer feedback as possible. I'd like to use this opportunity to cover our current changelog, establish a cadence for when you can expect product updates to both Code.xyz and StdLib to be announced, and finally, feature some feedback from the community.

Code.xyz Updates

  • Per popular request (thanks, Hugo!) we've improved cursor navigation in Code.xyz:

    • cmd + / (Mac), ctrl + / (Win) toggles // comments on selected lines (if not all commented, adds comments, otherwise removes)
    • cmd + ] (Mac), ctrl + ] (Win), tab on a highlighted selection adds indenting to every selected line
    • cmd + [ (Mac), ctrl + [ (Win), shift + tab on a highlighted selection removes indenting to every selected line
    • cmd + shift + z (Mac), ctrl + shift + z (Win) now acts as undo (joining previously enabled cmd + y / ctrl + y)
    • cmd + L (Mac), ctrl + L (Win) selects the current line (Unsupported in Safari)
    • cmd + c (Mac), ctrl + c (Win) on empty selection highlights and copies entire current line
    • cmd + x (Mac), ctrl + x (Win) on empty selection highlights and cuts entire current line
  • File Uploads are now supported (you can import files from your local filesystem)

    • Simply right click on the TreeView on the left and select "Upload Files..." — try it below!

StdLib Platform Updates

  • We've added a new function definition parameter, keys, which allows you to define function-specific API keys

For example, in functions/doAThing.js

* This is my endpoint function, called "doAThing"
* @keys MY_API_KEY
module.exports = async (context) => {
  // context is a "magic parameter"
  return context.keys.MY_API_KEY; // return API Key

You can pass in these keys to a StdLib function in one of two ways programmatically;

1. Using the lib-node Library

const lib = require('lib');
const myUsername = lib.myUsername({MY_API_KEY: 'someValue'});
let result = await myUsername.doAThing();
console.log(result); // returns "someValue"

2. Using an HTTP Request Directly

Simply set X-Authorization-Keys header to value {"MY_API_KEY":"someValue"} (JSON).

X-Authorization-Keys: {"MY_API_KEY":"someValue"}

Product Update Cadence

From this point forward, we will be posting Code.xyz and StdLib Platform updates on a weekly to bi-weekly cadence. We will never go more than two weeks without an update, and you can expect updates on Wednesdays before 9:00AM PT. This is our promise to our community — if there is any reason why Product Updates will take longer than a two week cadence, we will notify everyone ahead of time via our Twitter account, @StdLibHQ.

Community Feedback

We wanted to shine some light on some awesome community feedback we've received on Twitter since launching. If you'd like to be featured here in an update, feel free to tweet at us @StdLibHQ! We may use your feedback to fix a bug and thank you directly, or just include your kind words in a community post!

Chad Fowler (@chadfowler), CTO of Startup Advocacy at Microsoft...

Brian Leroux (@brianleroux), Co-founder at Begin...

Chris Munns (@chrismunns), Senior Serverless Developer Advocate at AWS...

Jared Short (@ShortJared), Director of Innovation at Trek10...

That's All for This Week!

Again, thank you so much for all the positive feedback and kind words! We'll be releasing more information in the coming weeks about the Code.xyz roadmap, our vision as to the future of API development, collaborative coding, and a whole lot more! Also, please keep in mind we're hiring, we'd love for you to consider joining us.


Keith Horwood
Founder and CEO, StdLib

We started StdLib in 2016 with a simple vision: web APIs should be first-class citizens of your development environment. Both developers and service providers should be able to publish, integrate with and manipulate Enterprise-grade APIs with the same ease-of-use they build and share documents or spreadsheets. We built the Standard Library serverless platform and API registry as a first step towards fulfilling this vision.

As it stands, Standard Library combines a scalable compute (hosting) layer with automatically generated documentation, authentication, billing, and more: enabling anybody to turn simple JavaScript functions into production-ready APIs in seconds.

Today, we are thrilled to talk about two major steps forward in our path to achieve the vision we’ve outlined:

  1. We are introducing a new product, Code.xyz, an in-browser code editor — an embeddable development environment for easily building APIs, webhooks, and workflow automation tasks that run atop StdLib infrastructure.

  2. We are humbled to officially announce $2M in strategic funding from Stripe, who many of you know as the payments platform for high-growth startups and technology-forward companies, bringing our funding total to $4M. They join a growing number of API and platform companies supporting us in our mission: Slack is an investor in our seed round, and MessageBird is both a customer and Enterprise partner of StdLib.


Code.xyz is an online code editor. It was carefully hand-crafted to power API development: specialized for webhooks, workflow automation tasks, and, of course, general API design tooling. You can think of it almost like the Google Docs for API development and publishing — our goal is to (1) significantly reduce repetitive API development work for professional engineers, as well as (2) increasingly provide less technical knowledge workers greater access to writing software and utilizing Enterprise-quality integrations.

Organizations can use the standalone editor on code.xyz to:

  • Quickly design and prototype APIs with complete documentation
  • Share these API design specs internally or with clients
  • Ship these APIs to production using immutable version control
  • Never worry about endpoint scaling: the StdLib cloud auto-scales
  • Manage and share API templates (sources) within your organization or the StdLib community as a whole

Additionally, you can use the editor as an embedded widget in your documentation:

  • Onboard developers to your APIs with shippable, production-ready examples
  • Provide customers the ability to write custom logic in response to webhooks

We’ll be releasing more features around embedding in the coming weeks. The widget you see below is a Code.xyz embed. We’ve pre-loaded it with a simple “hello world” API project. To get started, try simply hitting “Run” in the bottom right to build the function as an API and execute it.

Why Code.xyz?

At StdLib we have been very focused on the future of software development. Mostly, we’ve been ruminating on the question: how will serverless computing change software development? The answer jumped out at us pretty early on: by removing barriers to entry to shipping software, serverless computing allows developers to spend less time worrying about operational implementation of code and spend more time working on integration of pre-existing pieces, or shipping units of integration themselves. Hence, a library of software - a “standard library” of APIs.

We hypothesized that by building a “standard library” layer, and baking in hosting, scaling, documentation, SDK generation, gateway functionality and more as part of the product, the resulting abstraction layer would increasingly allow less technical individuals greater access to building and utilizing web-based compute and provide more technical individuals a rapid development, iteration, and shipping process for APIs.

For the last 18 months, we’ve relied on word-of-mouth and simple command line tooling to enable developers to build with the Standard Library platform. Though we’ve been humbled by the community response to date, after reaching tens of thousands of developers we identified two roadblocks to our continued growth. The first is that for less technical individuals, asking them to install command line tools introduces a pretty high barrier to entry to using our product. The second is that for more technical individuals, there is a lot of noise in the “serverless” computing space and attempting to explain what we provide at StdLib above and beyond a typical serverless platform is less effective than just showing developers through an intuitive, familiar web interface. Code.xyz was engineered from scratch to remove these roadblocks, providing a bespoke experience for our developers and community.

$2M in Financing from Stripe

Around the time we were trying to answer our questions about the future of software development, we managed to find a great connection with the team at Stripe. Stripe’s mission, to grow the GDP of the internet by enabling new business models and lowering the barriers to entrepreneurship, resonated immediately with our own goals. We strongly believe in lowering the barriers-to-entry to both software development and API integration as a means to propel businesses forward.

Today we are humbled to officially announce $2M in strategic financing from a company we deeply respect and admire, bringing our funding total to $4M. The team at Stripe has been amazingly forthcoming and a pleasure to work with. We are especially grateful to Patrick and John Collison for their unbelievable support of our vision — and we'd also like to give a shoutout to Romain Huet, who published a wonderful guide to Stripe Payments with StdLib on GitHub.

We look forward to creating a more open, easily accessible software and API development landscape for everybody. The serverless computing revolution is still in its infancy, with much more to build and create. We eagerly open our arms to new and veteran developers alike. We would be thrilled to have your support.

If you are as excited about the future of software and API development as we are, please do check out our open positions at StdLib.

Thank you for reading and being a part of our journey,

Keith Horwood
Founder and CEO, StdLib