# Integrating m3ter with Salesforce A meter is not a Salesforce product quantity until the mapping is written. The failure is a bill for usage that never happened. **Published:** 2026-08-31 **Canonical:** https://synconai.com/integrating-m3ter-with-salesforce **Author:** SynconAI Architecture Team ## In short Salesforce completed the m3ter acquisition on 1 July 2026. A meter is not a Salesforce product quantity until the mapping is written. This page has no price per API call. Name the meter, the quantity it may become, and the failure: a bill for usage that never happened. ## Sources - **Salesforce Signs Definitive Agreement to Acquire m3ter** (retrieved 2026-07-01) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-m3ter/ > Salesforce completed its acquisition of m3ter on July 1, 2026. ## What to take away - A meter is not a Salesforce product quantity until someone writes the mapping, including the unit and the direction. - There is no price per API call in the record. Do not invent one to finish a rate card. - The object is the usage the meter counted. It becomes a quantity only on the product you named. - The failure is a bill for usage that never happened, including a bill that filled a gap with a guess. ## The guide Finance sends the invoice on the usual day. The customer replies that the usage never happened. The meter for that product was silent for the period. Someone, or something, still placed a quantity on the Salesforce product, because a blank looked like a broken feed and a broken feed looked like a reason to estimate. The estimate became the bill. The customer is now arguing about a number your own meter does not support. That argument is the integration, seen from the wrong end. The close does not know your products, your units, or your prices. The integration is the meter, the Salesforce quantity it is allowed to become, and the failure when you bill for usage that never happened. A mapping written down is the difference between those. A mapping assumed is how the invoice goes out anyway. This page is the mapping and the three labels. The wider scope, including rating rules and what a quote should contain, is [m3ter, usage pricing, and Agentforce Revenue Management](/m3ter-agentforce-revenue). The acquisition record is [What happened to m3ter](/what-happened-to-m3ter). Use those when you need the build or the deal. Stay here until you can show which meter becomes which quantity, and what you do when the meter has nothing to say. ## What the cited page says The sentence this page quotes is the completion record: "Salesforce completed its acquisition of m3ter on July 1, 2026." Outside the quotation, the day is 1 July 2026. Completed means the deal is done. It does not mean your org gained a meter, a rate card, or a new quantity on a product that morning. The sentence does not contain a price per API call. Do not invent one. A number on a whiteboard, chosen because the room went quiet, is not a rate. It will be photographed, and the photograph will be treated as policy. Wipe it off. If you charge for usage, the price lives in a contract and a rating rule you write yourselves. This source will not supply either. The sentence also does not name a connector, a screen, a daily cap, or a unit. This page will not supply them. A unit is part of your mapping, and it is the unit you actually sell. If you cannot say the unit, you cannot map the meter. Do not borrow a unit because it is common in other companies. Their contract is not yours. What you can say is the shape of the work. A meter counts something a customer used. A Salesforce product quantity is a number on a product you sell. They are the same number only after a mapping says so, in writing, with an owner. Until that page exists, they are different objects, and billing as if they were the same is how you charge for usage that never happened. ## The system The system has two sides, and the mapping is the sentence that joins them. On one side, the meter. Name it in language your engineers and your finance partner both accept. What it counts. When it counts. What a zero means. What silence means. Zero and silence are different. Zero means the meter ran and saw nothing. Silence means you do not have a count. Treating silence as zero bills nothing and may be right. Treating silence as "same as last month" bills usage you did not see. Pick one, in writing, before the first invoice. On the other side, Salesforce. A product, and a quantity on that product. The quantity is not the meter. It is the number you are willing to bill, after the mapping. If the product does not exist yet, the integration is not ready. Creating a product so the meter has somewhere to land is a catalogue decision, owned by the people who own the price book. Do not let an integration ticket create a product as a side effect. The mapping is a sentence you can read aloud. This meter, in this unit, for this customer, becomes this quantity on this product, for this period. Include the direction. Meter to Salesforce is the bill. Salesforce to the meter is not a substitute when the meter is silent. Do not let a quantity already on the product flow backwards to "confirm" usage. That loop manufactures the failure: the bill proves the usage, and the usage was the bill. Name the person who owns the invoice. Metering without an invoice owner produces a feed that nobody is allowed to stop. The owner can delay a bill, send a zero, or hold for a human when the meter is silent. Those are business rules. They are not rounding. Write the rule next to the mapping. A developer default that estimates the gap is a price you did not approve. ## The object The object is the usage the meter counted, for a period, for a customer. It is not yet a Salesforce product quantity. It becomes that quantity when the mapping is applied, and not before. Say this in the design review until people stop drawing one box. A quantity without a meter reading beside it is not the object. It is a number. Numbers are easy to type and hard to defend when a customer asks what they did. Keep the reading, the period, and the customer identifier with the quantity you propose. If you cannot join them, do not bill. The object has edges. Usage before the mapping was agreed. Usage for a product you retired. Usage for a customer who is not in Salesforce yet. Each of those needs a decision that is not "put it on the nearest product". The nearest product is how a bill describes something the customer did not buy. Park the reading. Let a person place it, or discard it under a rule. There is no object called "API calls" on this page unless your mapping says that is the unit. The source does not. If your contract sells something else, map that. A diagram that says API calls because the room has heard the phrase is inventing a unit. Inventing a unit is as serious as inventing a price. Both end on an invoice. Partial periods need a sentence too. A customer who starts on the tenth of the month does not automatically owe a full month of usage. The meter may show a short count. The product quantity should show the same short count, if the mapping says counts pass through. If your commercial rule is different, the rule has to be written. It cannot be implied by the convenience of a monthly invoice run. ## The failure The failure is a bill for usage that never happened. The customer is right to dispute it. Your meter, if you still have the reading, will not support the line. Or the meter was silent, and the line was filled by a copy of a previous period, an average, or a typed estimate that made the invoice complete. Completeness is the usual motive. Finance has a calendar. A blank quantity looks like the integration is down. Someone fills the blank so the run succeeds. The run succeeds. The failure has been issued as a document the customer must now fight. A successful invoice run is not evidence that the usage happened. Test the silence on purpose. Pick a product with a meter you can pause, or a period you know is empty. Run the path that creates the quantity. The pass is no bill for that usage, or a zero you can explain from a real reading of zero, under the rule you wrote. The fail is a positive quantity with no reading. If the only way the test passes is that a person noticed and deleted the line, the system has not passed. The person is compensating for a rule you did not write. Also test the wrong product. Two products, one meter. The meter moves. The quantity must move on the mapped product and stay still on the other. A mapping that updates both, or updates "the active one", will bill for a product the customer did not use. That is the same failure in a cleaner shirt. Keep the reading you billed against. When the dispute arrives, you will want the count, the period, and the mapping version. A bill you cannot trace to a reading is already the failure, even if the customer has not written yet. ## The diagram A diagram that does not name the system, the object, and the failure is a poster. A meter icon, an arrow, and a Salesforce logo will be implemented as "sync usage nightly". Nightly sync is how a guess becomes a quantity while everyone sleeps. | Label | What this integration names | | --- | --- | | System | A named meter and a named Salesforce product, joined by a written mapping. The meter is not the quantity. | | Object | The usage counted for a customer and a period. It becomes a product quantity only through that mapping. | | Failure | A bill for usage that never happened. | If the mapping cell is empty, do not draw the arrow. An arrow without a unit, a product, and a silence rule is the poster. If someone writes a price per call on the picture, rub it out. This source does not have that price, and your invoice should not inherit a sketch. No connector name belongs in the corner. No screen belongs there either. You were not given one. The three labels are enough to build the first safe bill, and enough to refuse an unsafe one. ## What you write before the first billed quantity The meter. What it counts, the unit, and the difference between zero and silence. The product. The Salesforce product that may receive the quantity. The person who owns that product in the price book. The mapping sentence. Meter, unit, customer, product, period, direction. Version it. A changed sentence is a new mapping, not a quiet edit after invoices have gone out. The silence rule. Delay the invoice, bill zero from a real zero, or hold for a person. Estimates, if finance insists, are a written rule with a limit and an owner. They are not a developer default. This page would rather you did not estimate. If you do, the estimate must be visible as an estimate, not disguised as a reading. The trace. Where the reading is kept, next to the quantity, for long enough to answer a dispute. Out of scope. A price per API call. A quantity with no reading. A product created by the integration ticket. A win, in the sense of an invoice that went out on the usual day, when the meter was silent. Price the work as this list. Do not price it as a rate card you invented in the workshop. ## How the other two pages fit This page is the mapping and the bill you must be able to defend. It is not the whole commercial design. [What happened to m3ter](/what-happened-to-m3ter) is the close. The day, and what the record does not contain. Send arguments about the deal there. Do not let a headline set a unit or a price. [m3ter, usage pricing, and Agentforce Revenue Management](/m3ter-agentforce-revenue) is the build around metering and rating, including who owns the invoice and how to test a partner. Use it when this diagram is accepted and you are ready to scope the work. A partner who opens with a price per call has skipped the source and this page. :::warn A meter is not a Salesforce product quantity until the mapping is written. Do not put a price per API call on the diagram. The failure is a bill for usage that never happened, including a blank that was filled so the invoice run would succeed. ::: ## A first period you can explain Pick one product, one customer, and one period you understand. Include a stretch where you know the honest count is zero or the meter was silent. Apply the mapping. Read the quantity. Read the invoice line before it is sent. If the line matches a reading you can show, you may send it under your ordinary approval. If the line is positive and the reading is missing, do not send it. Fix the silence rule. Do not add a second product in the same period to look further along. A second product is a second mapping. It waits until the first bill is one you can defend in a dispute without inventing a count. When the diagram's three cells are filled from that period, you have an integration. When they are filled from the acquisition date and a guessed rate, you have a poster that can issue invoices. That is worse than a poster that only hangs on a wall. ## Questions ### What is the price per API call after the m3ter acquisition? This source does not set one. The acquisition completed on 1 July 2026. A price you charge is a contract and a rating rule you write. Do not copy a number from a whiteboard into a rate card. A missing price is not a reason to invent one so the diagram looks finished. ### When does a meter become a Salesforce product quantity? When the mapping is written. The mapping names the meter, the unit, the customer, the product, the period, and the direction. Until that sentence exists, the meter and the quantity are different objects. Do not bill as if they were the same. ### What is the failure in an m3ter integration? A bill for usage that never happened. It often starts as silence from the meter, filled so the invoice run can finish. A positive quantity with no reading is the failure. Zero from a real zero is a different case, and only if your written rule says so. ### What should we do when a period of usage never arrives? Follow the silence rule you wrote in advance. Delay the invoice, bill a genuine zero, or hold for a person. Do not quietly copy last month. An estimate, if you allow one at all, has to be visible as an estimate, with an owner and a limit. ### Which page is the build, and which is the deal? Rating, the invoice owner, and the partner test are on the m3ter implementation page. The close is on the what-happened page. This page is the diagram: meter, quantity, mapping, and the failure when the bill describes usage you cannot show. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Revenue Cloud (https://synconai.com/salesforce-revenue-cloud-advanced).