Zend Framework module ensuring at most once requests for mutating endpoints
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Idempotency module for Zend Framework

Zend Framework module ensuring at most once requests for mutating endpoints.

Latest Stable Version Software License Build Status Total Downloads

While the inherently idempotent HTTP semantics around PUT and DELETE are a good fit for many API calls, what if we have an operation that needs to be invoked exactly once and no more? An example might be if we were designing an API endpoint to charge a customer money; accidentally calling it twice would lead to the customer being double-charged, which is very bad.

This is where idempotency keys come into play. When performing a request, a client generates a unique ID to identify just that operation and sends it up to the server along with the normal payload. The server receives the ID and correlates it with the state of the request on its end. If the client notices a failure, it retries the request with the same ID, and from there it’s up to the server to figure out what to do with it.

Stripe describes its solution in a blog post which provided the inspiration for this package.



Idempotency module only officially supports installation through Composer. For Composer documentation, please refer to getcomposer.org.

You can install the module from command line:

$ composer require riskio/idempotency-module

After installation of the package, you have to copy the riskio_idempotency.global.php.dist file into your config/autoload folder and apply any setting you want.

  • source: vendor/riskio/idempotency-module/config/riskio_idempotency.global.php.dist
  • destination: config/autoload/riskio_idempotency.global.php

Zend Framework

In Zend Framework application, you must enable the module by adding Riskio\IdempotencyModule in your application.config.php file.

Zend Expressive

In Zend Expressive application, you must add the Riskio\IdempotencyModule\IdempotencyMiddleware middleware in config/pipeline.php file at the very first pipeline records.

use Riskio\IdempotencyModule\IdempotencyMiddleware;



The module goal is to guarantee the safety of operations on mutating endpoints by allowing clients to pass a unique value with the special Idempotency-Key header.

The clients are in charge of creating the unique keys. The module always send back the same response for requests made with the same key, and keys can't be reused with different request parameters.

Idempotency key format validation

By default, the module uses V4 UUIDs but you can change validation rules using the config file seen above:

use Zend\Validator\Uuid as UuidValidator;

return [
    'riskio_idempotency' => [
        'idempotency_key_validator' => UuidValidator::class,

Storage of already performed requests

In order to keep track of requests performed with Idempotency-Key header, you have to specify a PSR-6 cache compliant service. Keys will expire after a delay related to the lifetime of your cache.

use Symfony\Component\Cache\Adapter\NullAdapter as NullCacheAdapter;

return [
    'riskio_idempotency' => [
        'cache' => NullCacheAdapter::class,

For instance, Stripe has defined that the keys expire after 24 hours.

Idempotent requests serialization/deserialization

For each idempotent request, the module creates an instance of Riskio\IdempotencyModule\IdempotentRequest that contains a checksum of the HTTP request performed and the related HTTP response in order to be stored and eventually retrieved in the future if the request is made more than once.

Accordindly, we must provide a serializer that will serialize and unserialize this class. By defaut, the module uses the Riskio\IdempotencyModule\Serializer\Serializer class but you can provide another one if you want.

use Riskio\IdempotencyModule\Serializer\Serializer;

return [
    'riskio_idempotency' => [
        'serializer' => Serializer::class,

Eligible HTTP methods

RFC7231 (substituting RFC2616) added two notions to HTTP methods:

  • A safe HTTP method is a method that do not modify resources. For instance, using GET or HEAD on a resource URL, should NEVER change the resource. However, this is not completely true. It means: it won't change the resource representation. It is still possible, that safe methods do change things on a server or resource, but this should not reflect in a different representation.
  • An idempotent HTTP method is a method that can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. For subsequent calls, the answer will be the same all the time.
Method Safe Idempotent
GET yes yes
HEAD yes yes
POST no no
PUT no yes
PATCH no no
DELETE no yes

Accordingly to the RFC, only POST and PATCH HTTP methods are not idempotent. Consequently, the module allows clients to use Idempotent-Key header only for these methods by default. However, you can configure another HTTP method list to meet your needs as below:

return [
    'riskio_idempotency' => [
        'http_methods' => ['PATCH', 'POST'],

Idempotency key header customization

By default, the module uses Idempotency-Key header to submit unique tokens that guarantee idempotency of endpoints. If you want to use another header name for whatever reason, you can specify it as below:

return [
    'riskio_idempotency' => [
        'idempotency_key_header' => 'Idempotency-Key',


$ vendor/bin/phpspec run



The MIT License (MIT). Please see License File for more information.