skip to Main Content


This is the introduction page for all things IFSF API related. It’s a good place to start if you are unfamiliar with the new technology, jargon and tools associated with APIs, and you want a quick summary of what is available.

If you are familiar with APIs, Git Repositories, JSON and OAS 3.0 then you can jump straight to the Shared Git Repository here.


IFSF have been writing design rules, Implementation guides, an API Data Dictionary and developing collections of APIs since 2015.
Everything has been upgraded to current (Early 2020) best practise, to a git repository and are shared with Conexxus.
Previous versions are stored in the IFSF Standards archive under Part 4-01. These must no longer be used.
The current recommended versions are stored in open retailing git repositories, shared with Conexxus.
The design guides and dictionary are public. The APIs and tools (such as forecourt device simulator) are for members access only.

API Design Rules and Implementation Guides

Design Rules for JSON

Design Rules for APIs using OAS 3.0

Implementation Guide – Transport Layer

Implementation Guide – Security


Process and “How to” Guide

IFSF and Conexxus are developing short YouTube videos to introduce new people to the new technology and the way IFSF and Conexxus want to see it implemented. These will slowly become available on over time. The only examples currently are on the Conexxus web site (see API resources)

The main development platform is a Git Repository called GitLab. Git Lab documentation is excellent and comprehensive (although full of new jargon) and can be viewed here.

IFSF and Conexxus have adopted the standard Gitlab workflow; which is described here.

Gitlab workflow is very flexible and certain parts have bee specified in more detail – for example to enable our tools to work effectively.

These are described in  the Open Retailing GitLab Development Process document.


This document requires supporting documents to be produced and the templates for these can be found here . Specifically the templates include

API Resource Identification Template and an  example

Joint Conexxus-IFSF Threat Model Template – Designers

Joint Conexxus-IFSF Threat Model Template – Implementor


The process for approving an API – whether it initiated as a donated Api or from an IFSF or Conexxus Working Group is described in documents.

These documents can be found in the project Gitlab openretailing repository project folder called work-in-progress/api-design-guidelines.

As well as containing MS-Word versions of the design rules and Implementation guides (described below) it also contains:

Joint IP Submission Form

Open Retailing GitLab Development Process

Process for Donated APIs

Published API Collections

The following API Collections are in the openRetailing Git repository. You need to be a member of IFSF to access these. Contact and request access to all folders.

Forecourt API Collection: This covers all the Use Cases that are defined in Part 3-27  between a POS and FDC for fuel. That is everything except car wash and EPS. Specifically Dispensers, Price Poles, Prices and Tank Gauges are included.

WSM: This covers the five fundamental wet stock management use cases; i.e. Tank Stock, Movements, Turnover (from Dispenser meters), Sales (as registered at POS) and Fuel Reconciliation (identifies discrepancies).

REMC (Remote Equipment Monitoring and Control): This covers the maintenance management Use Cases for Asset Identification (equipment, devices and applications), Events (Error, Warning and Information) and Points (Reading values).

Remote Fueling Point Approval: This covers the most common above site authorisation Use Case for “mobile payment”. The single use case implemented is pre-auth (usually outdoor) for fuel only. Post-Pay, shop goods and services (e.g. car wash) are not included. No PCI relevant data is required (i.e. on site authorisation is not included).

Prices: This is a subset within the Forecourt-API-Collection. This covers the use cases for fuel and car wash (programme and options) pricing. Both setting and reporting prices between a client and server.

Simulators and Test Tools

IFSF and Conexxus have developed a Forecourt Device Controller Simulator to confirm that the Design Rules and Implementation Guides and the resulting Forecourt-API-Collection really work.

Forecourt Device Controller Simulator: The simulator is a simple prototype developed using eight of the Forecourt-API-Collection APIs. The simulator is running permanently on a cloud server and you can access it using the following URL’s.

Point of Sales MMI:

Fuelling Point MMI:

The source code for the Forecourt Device Controller Simulator and the two related MMI’s (HTML files) can be viewed here.

API Specification Validator: IFSF and Conexxus have developed a tool (actually a simple npm project) that consumes a .yaml API Definition File(s) and compares them with the Open Retailing Design Rules. The Forecourt-API-Collection was validated using this tool. The source code and how to run the tool can be found here.

Close search
Back To Top