Getting Started

View Source

This is an automatically generated Elixir client for the Mollie API, generated from their OpenAPI specification. A new version will be published daily if the OpenAPI specification changes.

Usage example

# mix.exs

# Add ONE OF the following to your deps in mix.exs.

defp deps do
  [
    # Install from hex.pm (RECOMMENDED)
    {:mollie_api, "~> 0.1.0-20251111"}

    # OR

    # Fetch from git.
    # The `sparse` causes a sparse checkout, so you only fetch the generated client code, not the _generator_ itself.
    # If you want to get the generator too, simple remote the `sparse` keyword argument.
    {:mollie_api, git: "https://gitlab.com/naslund-systems-public/elixir-mollie-api.git", tag: "0.1.0-20251111", sparse: "client/"},
  ]
end
# config/config.exs

# Disable soft-deprecation warning (see "Library shortcomings" below).
# Configure Tesla to use one of the recommended adapters (Mint, Finch or Hackney) instead of the default httpc.
# https://hexdocs.pm/tesla/readme.html
config :tesla, MollieAPI.Connection,
  disable_deprecated_builder_warning: true,
  adapter: Tesla.Adapter.Hackney
# application code.ex

connection = MollieAPI.Connection.new(bearer_token: "<YOUR MOLLIE API KEY>")
{:ok, response} =  MollieAPI.Api.PaymentsAPI.list_payments(connection)

This very basic example shows how to perform a simple call to the Mollie API.

All API calls happen through one of the modules in the MollieAPI.Api.* namespace. Responses will typically return a typed response in the form of a MollieAPI.Model.* struct.

The three building blocks Connection, Api and Model is everything you should need.

Library shortcomings

Not always the best ergonomics

This library is generated from the Mollie OpenAPI specification. This means the developer ergonomics aren't always the best, and you'll sometimes get seemingly unneccessary wrapper objects as part of the responses.

No testing

The library assumes the Mollie OpenAPI specification is correct and that the OpenAPI Generator produces correct code. There are no tests in place to verify that the generate client works as expected.

Non-semantic versioning

This library does regrettably NOT follow semantic versioning. Our versioning scheme looks like Major.Minor.Patch-YYYYMMDD, where the date represents the date the OpenAPI Specification was fetched. I'm afraid there aren't any changelogs available for the OpenAPI specification, so we can't easily tell when a major or minor change occurs. I recommend pinning the requirement to a specific version in your mix.exs.

Generated code uses soft-deprecated way to configure Tesla

The OpenAPI Generator for Elixir uses Tesla for HTTP requests, but the old and soft-deprecated way of doing so. This causes a warning to be emitted, which can be silenced as seen in the example below. Hopefully this will get fixed in the OpenAPI Generator for Elixir.

Not a lot of time allocated for maintenance

I generated this library mostly for my own needs. However after writing it I figured why not share it? I do however have limited time to devote to maintaining it. Smaller fixes will likely be implemented if requested.

Now you know all the caveats :). If you're OK with them, please make as much use as you like of this little library.