Weave Code
Csv Importer Laravel Package
firefly-iii/csv-importer
A command-line importer for bringing CSV bank statements into Firefly III. It maps CSV columns to transaction fields, supports multiple formats, validates and converts data, and can run interactively or from configuration files.
Firefly III CSV Importer Tool.
Frequently asked questions about Csv Importer
- Is firefly-iii/csv-importer a Laravel package I can install with Composer?
- No. firefly-iii/csv-importer is a standalone Laravel web application, not a library you composer require into an existing Laravel app. It runs as its own Docker-deployable service and acts as a client of the Firefly III REST API. There is no service provider, facade, or programmatic PHP entrypoint intended for third-party use.
- How do I install and run firefly-iii/csv-importer?
- Deploy it as a Docker container alongside your Firefly III instance. Set FIREFLY_III_URL and a Firefly III API token in the environment, expose the web port, and open the importer UI. There is no code integration or migration step in your own application.
- Which Laravel versions does firefly-iii/csv-importer support?
- Because the importer is a standalone application, its Laravel version is tied to the importer release you deploy, not to the Laravel version of your own application. It ships its own runtime and dependencies inside the container. Check the repository's composer.json and release notes for the exact framework version of a given tag.
- How does the CSV Importer connect to Firefly III?
- It connects over the Firefly III REST API using a base URL and a personal API token configured through environment variables such as FIREFLY_III_URL. The importer parses CSV rows, maps columns to Firefly III transaction fields, and posts the converted transactions to that API. It does not write directly to the Firefly III database.
- Can I use firefly-iii/csv-importer to import CSV data into a system other than Firefly III?
- Not realistically. The parsing, validation, and conversion logic is coupled to Firefly III's transaction schema and API contract, and there is no general-purpose ingestion interface. If your target is another finance system, you would be better served by a small purpose-built importer in your own stack. The importer only makes sense if Firefly III is your system of record.
- Does firefly-iii/csv-importer support different CSV formats and custom column mapping?
- Yes. The tool lets you map CSV columns to Firefly III transaction fields, which is how it handles different bank statement layouts and formats. It also validates and converts the mapped data before sending it to Firefly III. Complex or unusual CSV dialects may still require forking and extending the importer.
- Can firefly-iii/csv-importer run non-interactively from a configuration file?
- Yes. The importer can run interactively through its web UI or from configuration files, so recurring imports can be scripted rather than clicked through. That makes it suitable for scheduled monthly bank exports as well as one-off migrations. You still need a reachable Firefly III instance and a valid API token for each run.
- What should I consider before running firefly-iii/csv-importer in production?
- You are adding a second Laravel application to operate and patch, with its own database, dependency tree, and release cadence. The tool handles full financial transaction exports, so API token storage, TLS to Firefly III, and container network exposure are audit-relevant. Plan for container image updates and a clear owner for patching, because upstream maintenance may lag.
- How can I test firefly-iii/csv-importer safely before importing real bank data?
- Point the importer at a staging or disposable Firefly III instance and use a small sample CSV to verify column mapping, date parsing, and transaction output. Confirm the API token has only the permissions the importer needs. Once the mapping is correct, repeat the process against production with a known backup in place.
- Is firefly-iii/csv-importer actively maintained, and what are the alternatives?
- Adoption and community visibility are low, so treat maintenance as something your team owns rather than assuming upstream will handle it. Issue triage may be slow, and public integration examples are scarce. Alternatives include a thin internal importer against the Firefly III API, forking and extending this codebase, or using it as-is only if Firefly III is already your system of record.
Weaver
How can I help you explore Laravel packages today?